Espeasy: [ОШИБКА] [Стабильность Wi-Fi] Исключение ESP 3/29 при отключении уровня 2

Похоже, у меня такая же проблема. Иногда мой esp терял соединение с Wi-Fi и часами не подключался к Wi-Fi. Я думал, что они должны перезагрузиться и повторно подключиться к Wi-Fi благодаря сторожевому таймеру, но они этого не делают. Холодная перезагрузка решает проблему.

Последнее, что описал @wolverinevn, я тоже видел здесь.

как мы обсуждали в # 1957, я совершенно уверен, что многие из этих странных проблем с Wi-Fi / сетью происходят из-за нестабильности уровня 2 ... Я видел все виды странного поведения, прежде чем изменить свою точку доступа на некоторое увеличенное время ...

как мы обсуждали в # 1957, я совершенно уверен, что многие из этих странных проблем с Wi-Fi / сетью происходят из-за нестабильности уровня 2 ... Я видел все виды странного поведения, прежде чем изменить свою точку доступа на некоторое увеличенное время ...

Надеюсь, вы найдете решение. Один из моих Nodemcu зависает и пропадает с маршрутизатора в течение 5 часов без причины. Я надеюсь, что он сможет восстановиться после сторожевого пса, но ничего не происходит. Теперь мне нужно перезагрузить его вручную. Очень раздражает!

@wolverinevn, когда у вас снова будет доступ к узлу, перейдите в tools => advanced и установите «Порог сбоя подключения» на значение, отличное от 0 (я предлагаю что-то от 50 до 100, в зависимости от количества задач, которые у вас есть). На самом деле это не решает проблему, но значительно увеличивает вероятность перезагрузки узла и повторного подключения!

другой обходной путь был бы, если бы вы могли настроить некоторые параметры в своей точке доступа, в зависимости от того, какой тип AP у вас есть, если это можно настроить ...

@ clumsy-stefan Должны ли мы также установить этот уровень по умолчанию в ESPeasy?

И, может быть, нам также следует отобразить это значение на странице sysinfo и сделать его доступным для правил?

@ TD-er установка некоторого уровня по умолчанию, вероятно, неплохая вещь, если она не слишком низкая (всегда может случиться, что соединение не удастся).

При отладке проблемы я подумал, как это делается: в настоящее время каждое неудачное соединение увеличивает счетчик, а любое успешное соединение уменьшает его. Я подумал, было бы логичнее сбросить его до 0, как только произойдет успешное соединение, но я думаю, что это немного идеологический вопрос, что имеет больше смысла.

Проблема с этим числом заключается в том, что если у вас есть 10 задач, каждая из которых имеет количество повторов 10 и задержку повторной отправки 100 мс, перезагрузки происходят довольно быстро, если есть реальная проблема связи (100 попыток в течение примерно 10 секунд). .

теперь, если у вас, например, всегда 5 сбоев связи и 1 успешный, вы постоянно увеличиваете количество сбоев подключения. если это происходит постоянно, вы рано или поздно перезагрузите узел, даже если все данные могут быть доставлены.

Однако основная проблема, которую я вижу, заключается в том, что каким-то образом узел не понимает, что соединение на уровне 2 фактически пропало, и продолжает отправлять данные (я думаю). Помимо того, что я понял сегодня вечером, что происходит с системным журналом (и другими коммуникациями, такими как NTP и т. д.), если нет подключения к Wi-Fi? Это тоже остановлено? это могло бы объяснить, почему мои узлы внезапно перескакивают на 100% ЦП, когда уровень 2 отсутствует. вероятно, данные о задачах больше не отправляются, но он пытается избавиться от пакетов системного журнала UDP и не может ... просто предположить ...

извините, длинный текст на два простых вопроса ... короче:
уровень по умолчанию: да, я бы установил его на максимум (100) или около того по умолчанию ... если все в порядке, это не повредит, если нет, устройство снова станет доступным ...
Страница sysinfo и правила: я бы сказал нет, почему это должно динамически изменяться? это аварийные значения ...

@ clumsy-stefan Я уже установил 50. Давай подождем. ;)

@wolverinevn хмм ... 50 должно произойти довольно быстро в зависимости от количества интервалов задач и повторных попыток (5-15 мин.) ... если это не поможет, я думаю, что узел на самом деле не заморожен, но это просто может ' t переподключиться к сети. У меня такое тоже было даже после перезагрузки WD. вы можете увидеть, пытается ли узел перейти в режим AP? вы видите AP-WLAN узла?

Страница sysinfo и правила: я бы сказал нет, почему это должно динамически изменяться? это аварийные значения ...

Я хотел, чтобы меня проверили в правилах, используя системную переменную, например %conn_fail% и покажите ее на странице sysinfo рядом с количеством повторных подключений Wi-Fi.
В конце концов, это значение статистики производительности

Я хотел, чтобы меня проверили в правилах, используя системную переменную, например% conn_fail%, и отобразите ее на странице sysinfo рядом с количеством повторных подключений Wi-Fi. В конце концов, это значение статистики производительности

ах, да, согласен, в этом есть смысл! это тоже немного связано с выпуском №1993. Было бы здорово иметь плагин, который регулярно отправляет ряд переменных системы / производительности в контроллер (не тратя зря ограниченные доступные задачи)!

@wolverinevn хмм ... 50 должно произойти довольно быстро в зависимости от количества интервалов задач и повторных попыток (5-15 мин.) ... если это не поможет, я думаю, что узел на самом деле не заморожен, но это просто может ' t переподключиться к сети. У меня такое тоже было даже после перезагрузки WD. вы можете увидеть, пытается ли узел перейти в режим AP? вы видите AP-WLAN узла?

У меня 9 задач, 3 из них Dummy и MQTT_import. Я думаю, что правила немного заняты вычислениями и считыванием датчиков, я пытался ограничить mqtt_publish, вызывая правила каждые несколько минут. Нагрузка около 29%.
Насколько я помню, в прошлый раз, когда он был заморожен сегодня утром, я не могу найти AP Espeasy (если вы имеете в виду, что AP_WLAN работает в режиме AP).
Моя установка (сеть, расположение ESP) отлично работала с другим Nodemcu под управлением 2.3 или 2.4, выпущенным в марте.

_Uptime составляет 7 часов 20 минут, RSSI -71 дБм, вокруг меня есть несколько Wi-Fi.
Причина последнего отключения: | (200) Тайм-аут маяка
Номер переподключается: | 35_

@wolverinevn проблема в том, что это происходит совершенно случайно. У меня работает ~ 30 узлов, некоторые из них столкнулись с проблемой, некоторые из них нет, некоторые перезагружены, некоторые перешли в режим AP ...

Это действительно похоже на комбинацию того, насколько загружен узел, насколько загружен эфир (например, количество устройств Wi-Fi) и как ваша точка доступа фактически обрабатывает определенные условия (отсутствие подтверждения уровня 2 и т. Д.) ...

так что я думаю, пока мы не найдем в приложении (ESPEasy) способ надежно обнаружить это состояние и действовать в соответствии с ним, «настоящего» решения не будет ...

@wolverinevn PS: ты случайно не пользуешься AP mikrotik?

@wolverinevn О количестве переподключений (в вашей редакции)
35 переподключений примерно за 8 часов - это много.
У меня есть узлы, работающие здесь в течение нескольких дней, которые имеют всего несколько повторных подключений.
Самый стабильный сейчас работает 20 дней 11 часов 46 минут и только 1 переподключение.

Подключено | 19д22х33м
- | -
Причина последнего отключения | (202) Ошибка аутентификации
Номер переподключается | 1

@wolverinevn PS: ты случайно не пользуешься AP mikrotik?

Нет. Я использую роутер с прошивкой Padavan (вроде ASUS).

@ TD-er Я знал это. Я ищу причину, может быть шум от модуля понижающего заряда поблизости. У другого 0 переподключений через 2 часа.

Нет. Я использую роутер с прошивкой Padavan (вроде ASUS).

К сожалению, я вообще не знаю эту прошивку ... Есть ли шанс настроить параметры уровня 2? Что-то вроде таймаутов подтверждения кадра или чего-то подобного? Какие-то настройки "расстояния"?

@ clumsy-stefan К сожалению, я не вижу ничего подобного.

@ clumpsy-stefan Прошлой ночью устройство было перезагружено 2 раза с установленным порогом отказа 50. Хорошие новости: заморозки больше нет. Сегодня я постараюсь улучшить подключение к Wi-Fi, внеся небольшие изменения в настройку оборудования.

3 устройства Wemos в одной комнате, подключенные к одной точке доступа.
Повторно подключается за последние 16 часов или около того,
С правилом: On WiFi # Connected ....

26 перезагрузок WD и 104 переподключения:

9 перезагрузок WD и 32 переподключения

2WD перезагружается и 40 повторных подключений

У всех установлено 50 пороговых значений отказов

@Domosapiens & @wolverinevn еще одна вещь, которую вы можете попробовать - это увеличить время ожидания группового ключа на вашей AP (если у вас есть такая возможность). Обычно это около 5 минут. Можно попробовать увеличить до 30мин. или даже 1 час и посмотрите, не повлияет ли он (если он не находится в сети со сверхвысокой степенью безопасности, чего я не предполагаю, если в ней есть IoT) ...

@ TD-er

Самый стабильный сейчас работает 20 дней 11 часов 46 минут и только 1 переподключение.

У меня также есть устройства, которые работали более 3 дней, а другие перезагружались в течение дня ...

Я заметил некоторые проблемы с повторным вводом группового ключа. почему-то кажется, что в более новых версиях ядра может случиться так, что изменение ключей запускается по таймауту ... однако приложение должно действовать в соответствии с этим, а не переходить в какой-то режим с высокой нагрузкой, не реагирующий ... но я не уверен, где он терпит неудачу ..

@ clumsy-stefan спасибо за ваше предложение.
Я вижу в моем маршрутизаторе dd-wrt параметр. «Интервал обновления ключа» со значением 3600 (в секундах).
Так что все должно быть хорошо?

при смене ключей истекает тайм-аут

Это объяснило бы только ежечасное повторное подключение imho.
Благодаря замечательной функции правил _WiFi # Connected_ мы можем это увидеть.
Понятия не имею, как старые версии справились с этим.
Скрытая проблема уже давно?

после установки моего группового ключа reneval с 5мин. до 1 часа агрегаты работают намного стабильнее. Я предполагаю, что с 40 клиентами, подключенными к одной AP, делают это каждые 5 минут. rekey только что получил эфир слишком занят ... после этого я мог даже снова уменьшить время ожидания кадра, и устройства снова стали более отзывчивыми, также у меня стало меньше "таймаутов соединения" после изменения этих параметров ...

@ TD-er, тем не менее, я думаю, что этот "тайм-аут группового ключа" и последующий "сбой связи" должны быть зафиксированы и обработаны приложением. У меня такое ощущение, что устройство продолжает пытаться отправлять сообщения в очереди на контроллер / сервер, пытаясь выполнить повторный ключ, что делает устройство слишком медленным и повторный ввод не работает ... поэтому отключается на уровне 2.

это всего лишь приблизительная идея, я все еще пытаюсь понять ее, но это самое близкое, что я мог получить до сих пор.

@ TD-er jsut теперь я снова столкнулся с узлом, который входит в неопределенный цикл попыток повторного подключения и всегда истекает (см. Журнал ниже). Интересно то, что он явно понимает, что не подключен, и не пытается отправить данные в контроллер, что означает, что количество «неудачных попыток подключения» больше не увеличивается и, следовательно, никогда не достигает предела неудачных подключений.

также загрузка всегда показывает 100%, поэтому я думаю, что не удается повторно подключиться, так как это всегда слишком медленно, чтобы действительно выполнить рукопожатие .... похоже, что у меня есть хвост ... просто память медленно уменьшается (пока Я предполагаю, что он вылетает из-за нехватки памяти) ...

Я собираюсь протестировать с # 2073 и посмотреть, повторится ли эта ситуация снова ... однако это происходит очень редко на двух последовательных узлах, так что я могу действительно отслеживать, что происходит ...

105587 : EVENT: WiFi#Disconnected
3105617 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 129 ms
3131325 : WD   : Uptime 52 ConnectFailures 84 FreeMem 12976
3134621 : EVENT: WiFi#Disconnected
3134652 : WIFI : Disconnected! Reason: '(15) 4way handshake timeout' Connected for 5141 ms
3141487 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3141488 : WIFI : Connecting clumsy_ap2 attempt #53
3142671 : EVENT: WiFi#Disconnected
3142700 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 1122 ms
3153443 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3153444 : WIFI : Connecting clumsy_ap2 attempt #54
3153713 : EVENT: WiFi#Disconnected
3153743 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 157 ms
3161324 : WD   : Uptime 53 ConnectFailures 84 FreeMem 12976
3165518 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3165519 : WIFI : Connecting clumsy_ap2 attempt #55
3178542 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3178543 : WIFI : Connecting clumsy_ap2 attempt #56
3179728 : EVENT: WiFi#Disconnected
3179757 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 1122 ms
3189704 : SYS  : 31.00,12808.00,100.00,53.00
3189708 : EVENT: sysinfo#rssi=31.00
3189743 : EVENT: sysinfo#mem=12808.00
3189773 : EVENT: sysinfo#load=100.00
3189804 : EVENT: sysinfo#uptime=53.00
3191297 : WD   : Uptime 53 ConnectFailures 84 FreeMem 12800
3191441 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3191442 : WIFI : Connecting clumsy_ap2 attempt #57
3191576 : EVENT: WiFi#Disconnected
3191606 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 125 ms
3200507 : EVENT: Clock#Time=Tue,10:25
3204458 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3204459 : WIFI : Connecting clumsy_ap2 attempt #58
3217493 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3217493 : WIFI : Connecting clumsy_ap2 attempt #59
3218677 : EVENT: WiFi#Disconnected
3218707 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 1122 ms
3221325 : WD   : Uptime 54 ConnectFailures 84 FreeMem 12800
3245444 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3245445 : WIFI : Connecting clumsy_ap2 attempt #61
3249673 : SYS  : -80.00,12632.00,100.00,54.00
3249677 : EVENT: sysinfo#rssi=-80.00
3249709 : EVENT: sysinfo#mem=12632.00
3249741 : EVENT: sysinfo#load=100.00
3249772 : EVENT: sysinfo#uptime=54.00
3250620 : EVENT: WiFi#Disconnected
3250650 : WIFI : Disconnected! Reason: '(15) 4way handshake timeout' Connected for 5130 ms
3251307 : WD   : Uptime 54 ConnectFailures 84 FreeMem 12624
3259435 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3259436 : WIFI : Connecting clumsy_ap2 attempt #62
3260490 : EVENT: Clock#Time=Tue,10:26
3260650 : EVENT: WiFi#Disconnected
3260679 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 1121 ms
3273521 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3273522 : WIFI : Connecting clumsy_ap2 attempt #63
3273659 : EVENT: WiFi#Disconnected
3273689 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 125 ms
3281281 : WD   : Uptime 55 ConnectFailures 84 FreeMem 12624
3287445 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3287446 : WIFI : Connecting clumsy_ap2 attempt #64

С rssi - 80 сложно подключиться

Значение RSSI не является надежным, если узел ESP не подключен! у того же узла меньше -70 при подключении .... на узлах глубокого сна они даже показывают значение по умолчанию +31 "не подключен" при отправке значений!
и после перезагрузки он работает без проблем ... (без перемещения ...), если вы читаете выше, это проблема уровня 2, которая воспроизводится, когда вы настраиваете параметры на AP ....

PS: можете попробовать сами! Просто подключите 20-30 узлов и уменьшите таймаут группового ключа до 5 минут. и пороговое значение ответа кадра примерно до 7 ... посмотрим, что произойдет!

Я думаю, что это неправильное место для проблем со слоем 2, вам следует заполнить проблему на ядре esp8266 или, может быть, лучше на проекте nonos sdk
Но пожалуйста, не кричи здесь

это происходит только с ESPeasy, а не с другими типами прошивок, которые я пробовал. Я предполагаю, что узел становится слишком занятым в какой-то момент времени и не оставляет достаточно времени ядру для смены ключей (все объяснялось несколько раз), поэтому не стесняйтесь читать отладки и объяснения ...
но я согласен, на самом деле тебе не нужно отвечать ...
PS: @ uzi18 было ли у вас когда-либо

@ TD-er: в ESPEasyWifi.ino строках 650-669 соответствие оператора switch по умолчанию выходит за пределы switch, и поэтому tryConnectWiFi() возвращает true даже если WiFi.status() не обязательно WL_CONNECTED но может быть любым другим состоянием (проверяются только 2 состояния ложного возврата ..).

Изменение этого и возврат true только в том случае, если WiFi.status() действительно вернул WL_CONNECTED решает по крайней мере одну из проблем с отключением / исключением уровня 2, с которыми я столкнулся!

Что вы думаете?
Я что-то упустил или почему tryConnectWiFi() возвращать, если WiFi.status() не является? WL_CONNECTED`?

@ clumsy-stefan Приятно видеть, что вы все еще копаетесь в коде WiFi.

https://github.com/letscontrolit/ESPEasy/blob/5ee18ec556c9c58802af29f5fd78593905ef35c1/src/ESPEasyWifi.ino#L604 -L671

Первоначальная идея этой функции заключалась в запуске последовательности подключения WiFi.
Возможно, с тех пор его функция немного изменилась.
Но, возможно, вы здесь что-то заметили.
Я думаю, что это может быть правильное изменение return true (в конце этой функции) только в том случае, если возвращается статус, он подключен.

Можете ли вы описать, что, по-видимому, является другой проблемой уровня 2, с которой вы столкнулись?

не могу точно сказать, когда возникает другое исключение, но, по крайней мере, есть разница, если эта функция возвращает только true при статусе WL_CONNECTED Я прикрепляю отладку до и после изменения. .

до

156874 : EVENT: WiFi#Disconnected Processing time:74 milliSeconds
156876 : WIFI : Disconnected! Reason: '(0) Unknown' Connected for 2 m 32 s
156877 : WIFI  : Arduino wifi status: WL_CONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_DISCONNECTED
157208 : WIFI : Connecting clumsy_ap2 attempt #0
157212 : WIFI  : Arduino wifi status: WL_DISCONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_DISCONNECTED
scandone
160069 : Fatal exception 9(LoadStoreAlignmentCause):
epc1=0x40105cd4, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000003, depc=0x00000000

Exception (9):
epc1=0x40105cd4 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000003 depc=0x00000000

после

108304 : EVENT: WiFi#Disconnected Processing time:73 milliSeconds
108307 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 2014 ms
108308 : WIFI  : Arduino wifi status: WL_DISCONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_DISCONNECTED
109217 : WIFI : Connecting clumsy_ap2 attempt #1
109220 : WIFI  : Arduino wifi status: WL_DISCONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_DISCONNECTED
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt

connected with clumsy_ap2, channel 9
dhcp client start...
112113 : WIFI : Connected! AP: clumsy_ap2 (4C:5E:0C:39:F6:55) Ch: 9 Duration: 2895 ms
112115 : WIFI  : Arduino wifi status: WL_DISCONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_CONNECTED
ip:10.0.10.117,mask:255.255.0.0,gw:10.0.0.2
113751 : WIFI : DHCP IP: 10.0.10.117 (wemos-mini-17-17) GW: 10.0.0.2 SN: 255.255.0.0   duration: 1636 ms
113765 : EVENT: WiFi#Connected

Хм ... Я просто понимаю, что после этого внутренний статус (пока) не соответствует статусу Arduino ... это также может привести к проблемам, я думаю ...

@ clumsy-stefan этот статус связан с тем, что мы не можем передавать статус Wi-Fi Arduino, поэтому @ TD-er представил статус ESPEasy, но хорошо, возможно, мы можем попытаться дважды проверить, правильно ли проверены все статусы в коде.

Возможно, этот статус Wi-Fi был исправлен в ядре 2.5.0, так что, возможно, наш собственный статус устарел.
Это было бы неплохо, так как это делает код WiFi довольно сложным и, следовательно, подверженным ошибкам.

Редактировать:
Я смотрю на эту ошибку, которую вы дали:
Fatal exception 9(LoadStoreAlignmentCause):
Одно из последних исправлений в ядре 2.5.0 касается конструктора IPAddress , который должен устранять проблемы, когда выравнивание данной последовательности байтов не выровнено по 32-битному разряду.
Может это что-то похожее?

Это одна из моих догадок, что статус ESPEasy не всегда синхронизируется со статусом Arduino. В частности, временные отключения на уровне 2 (например, изменение ключей Wi-Fi), вероятно, на самом деле не обрабатываются / не реализуются.

Еще одна вещь может быть противоположной: ESPEasy считает, что отключен, и пытается повторно подключиться, но ядро ​​все еще подключено, и поэтому приводит к исключению. но пока не могу это доказать ...

насчет расклада, да, может быть, но сейчас тоже не могу ...

так что единственное, в чем я уверен на данный момент, это то, что код возврата tryConnectWiFi() должен соответствовать фактическому статусу соединения или, по крайней мере, проверять наличие WL_CONNECTED ...

@ TD-er Меня больше беспокоит

connected with clumsy_ap2, channel 9
dhcp client start...
112113 : WIFI : Connected! AP: clumsy_ap2 (4C:5E:0C:39:F6:55) Ch: 9 Duration: 2895 ms
112115 : WIFI  : Arduino wifi status: WL_DISCONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_CONNECTED

Для меня последние две строки указывают на то, что ядро ​​еще не обновило статус, хотя ESPEasy считает, что это произошло ... так что здесь может возникнуть какое-то состояние гонки ...

после этого иногда я начинаю видеть много

7989956 : Read settings: ControllerSettings index: 0
7989997 : Read settings: ControllerSettings index: 0
7990130 : Read settings: ControllerSettings index: 0
7990267 : Read settings: ControllerSettings index: 0
7990399 : Read settings: ControllerSettings index: 0
7990531 : Read settings: ControllerSettings index: 0
7990664 : Read settings: ControllerSettings index: 0
7990799 : Read settings: ControllerSettings index: 0
7990938 : Read settings: ControllerSettings index: 0

от которого он никогда не оправится ...

чуть позже он мне говорит:

8185850 : ip:169.254.37.119,mask:255.255.0.0,gw:0.0.0.0
Read settings: ControllerSettings index: 0
8185975 : WIFI : DHCP IP: 169.254.37.119 (wemos-mini-18-18) GW: (IP unset) SN: 255.255.0.0
8185990 : EVENT: WiFi#Connected

Не знаю, откуда это ... но после этого он начинает пытаться подключиться к контроллеру / серверу, что, очевидно, терпит неудачу, пока не закончатся попытки (100) и не перезагрузится ...

РЕДАКТИРОВАТЬ: кстати, вы можете заставить это поведение, если вы отключите узел от AP вручную ... иногда он просто повторно подключается, иногда происходит то, что описано выше ...
EDIT2: иногда он вылетает из-за исключения 9 ... так что кажется, что это какое-то состояние гонки, как именно оно восстанавливается после отключения! по моей вине был addLog() в onDisconenct() ...

это более или менее всегда одна и та же ситуация. после того, как четырехстороннее рукопожатие не удается (повторное подтверждение), оно больше не восстанавливается ... не знаю, как принудительно восстановить это ..

по крайней мере, добавление некоторого количества delay(100) в processConnect() и processDisconnect таким образом, давая ядру время для обновления статуса WiFi, заставляет WiFi снова синхронизироваться. Это также значительно снижает вероятность попадания юнитов в следующую ситуацию!

900695 : WIFI : DHCP renew probably failed
900697 : Reset WiFi.
900699 : WIFI : Connecting clumsy_ap2 attempt #0
901713 : EVENT: WiFi#Disconnected
901772 : WIFI : Disconnected! Reason: '(8) Assoc leave' Connected for 14 m 56 s
902326 : WD   : Uptime 15 ConnectFailures 44 FreeMem 20248 WiFiStatus 0
907048 : EVENT: WiFi#Disconnected
907106 : WIFI : Disconnected! Reason: '(15) 4way handshake timeout' Connected for 6172 ms
907786 : WIFI : Connecting clumsy_ap2 attempt #1
911821 : EVENT: WiFi#Disconnected
911879 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 3860 ms
911894 : WIFI : Connecting clumsy_ap2 attempt #2
912793 : EVENT: Clock#Time=Sat,08:29
919974 : EVENT: WiFi#Disconnected
920033 : WIFI : Disconnected! Reason: '(15) 4way handshake timeout' Connected for 7962 ms
920824 : WIFI : Connecting clumsy_ap2 attempt #3
922083 : EVENT: WiFi#Disconnected
922141 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 1125 ms
922805 : WIFI : Connecting clumsy_ap2 attempt #4
923138 : EVENT: WiFi#Disconnected
923196 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 133 ms
925831 : WIFI : Connecting clumsy_ap2 attempt #5
931179 : EVENT: WiFi#Disconnected
931238 : WIFI : Disconnected! Reason: '(15) 4way handshake timeout' Connected for 5165 ms
931775 : WIFI : Set WiFi to AP+STA
932701 : EVENT: WiFi#APmodeEnabled
932778 : WIFI : AP Mode ssid will be wemos-mini-17_17 with address 192.168.4.1
932778 : WIFI : Connecting clumsy_ap2 attempt #6
933023 : WD   : Uptime 16 ConnectFailures 44 FreeMem 17856 WiFiStatus 0
934065 : EVENT: WiFi#Disconnected
934122 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 1123 ms
935712 : WIFI : Connecting clumsy_ap2 attempt #7
936042 : EVENT: WiFi#Disconnected
936106 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 169 ms
938745 : WIFI : Connecting clumsy_ap2 attempt #8
939079 : EVENT: WiFi#Disconnected
939138 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 131 ms
941778 : WIFI : Connecting clumsy_ap2 attempt #9
947130 : EVENT: WiFi#Disconnected
947189 : WIFI : Disconnected! Reason: '(15) 4way handshake timeout' Connected for 5140 ms
947725 : WIFI : Connecting clumsy_ap2 attempt #10
948976 : EVENT: WiFi#Disconnected
949035 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 1121 ms
951805 : WIFI : Connecting clumsy_ap2 attempt #11
952140 : EVENT: WiFi#Disconnected
952199 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 134 ms
955778 : WIFI : Connecting clumsy_ap2 attempt #12
956115 : EVENT: WiFi#Disconnected
956174 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 142 ms
959734 : WIFI : Connecting clumsy_ap2 attempt #13
960064 : EVENT: WiFi#Disconnected
960123 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 129 ms

@ TD-er tryConnectWiFi() возвращает true или false в случае, если соединение было успешным или нет ... однако WiFiConnectRelaxed() самом деле никогда не проверяет это ...

это функция как-то раньше, основанная на событиях WiFi? похоже, что он никогда не достигает последних 2 строк в этой функции ...

Да, это был какой-то пережиток до событийного Wi-Fi.
Я думаю, нам действительно стоит подумать о том, чтобы еще раз хорошенько взглянуть на этот код WiFi, поскольку он не так структурирован, как должен быть.

хорошо ... Я все еще отлаживаю, что именно происходит из-за тайм-аута 4-стороннего рукопожатия и почему узел не подключается снова ... но я думаю, что я все еще немного ковыряюсь в темноте, но нахожу здесь небольшие биты там, что могло сложиться хотя ....

еще один маленький, кажется, находится в WifiCheck() ... там проверка подключения уровня 2 выполняется только тогда, когда IP больше не действителен (например, все октеты равны 0). Это может привести к ситуации, когда уровень 2 отключает (или повторно) устанавливает соединение / подтверждение связи и т. Д., Но IP-адрес все еще действителен, поскольку срок его действия еще не истек (DHCP). Вероятно, это причина того, что «продление DCHP, вероятно, не удалось» происходит только через долгое время, когда договор аренды фактически истек ... но я все еще проверяю это ...

также есть wifiCheck() , WiFiConnected() и connectionCheckHandler() которые выполняют какую-то проверку соединения и при определенных условиях вызывают друг друга, а также resetWiFi() . . особенно connectionCheckHandler() кажется, вызывается только тогда, когда mqtt_reconnect_count > 10 . Так что же происходит в среде без MQTT?

PS: Я просто документирую свои выводы здесь в поисках основных проблем с WiFi ... Так что я рад любым мыслям по этому поводу, но не обязательно ожидаемому ...

где-то должно быть какое-то загадочное состояние гонки. когда AP инициирует повторную проверку подлинности или повторное подтверждение, иногда узел / ядро ​​либо не получает достаточно времени процессора для завершения рукопожатия, либо прерывается при этом, особенно на узлах с низким уровнем сигнала (и, следовательно, рукопожатие занимает гораздо больше времени). . (Смотри ниже).

эти повторные проверки / повторные проверки, похоже, генерируют событие отключения ядром, даже если ядро ​​выполняет автоматическое повторное согласование или повторное согласование (как я понимаю). но затем кажется, что этот процесс установления связи прерывается конечным автоматом ESPEasy, когда запускается ручное переподключение ... этот процесс повторяется и никогда не заканчивается (или в некоторых случаях генерирует wdt) ..

` 810114 : EVENT: WiFi#Disconnected 810146 : WIFI : Disconnected! Reason: '(16) Group key update timeout' Connected for 13 m 16 s 810977 : WIFI : Connecting clumsy_ap2 attempt #0 811081 : WIFI : Connection lost to: clumsy_ap2 813089 : EVENT: WiFi#Disconnected 813120 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 2011 ms 814977 : EVENT: Clock#Time=Thu,08:55 821529 : WD : Uptime 14 ConnectFailures 0 FreeMem 22000 WiFiStatus 0 831976 : WIFI : Connecting clumsy_ap2 attempt #1 832079 : WIFI : Connection lost to: clumsy_ap2 836831 : EVENT: WiFi#Disconnected 836863 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 4753 ms

Так, может быть, нам следует использовать события Wi-Fi только для отслеживания процесса, а не принимать меры самостоятельно?
Однако изменение этого параметра сделает сборки 2.3.0 и, возможно, 2.4.0 непригодными для использования.

Нет, я бы не стал этого делать ... В своей ветке я уже сделал пару (не очень навязчивых) изменений, которые, кажется, делают такие случаи реже ...

только что нашел еще одну мелочь: в tryConnectWiFi() проверка WiFi.status() идет до конца после того, как вызов WiFi.begin() начинает возвращать WL_DISCONNECTED . Согласно документации это означает «если модуль не настроен в режиме станции». пытаясь выяснить, почему это происходит, или на самом деле помогает ли это явно перевести esp в режим AP перед вызовом WiFi.begin()

Так что я все еще надеюсь найти "настоящую" основную проблему, почему эти киоски случаются ... Если так (скрестив пальцы), я бы предложил, чтобы я сделал PR со всеми изменениями, чтобы вы (и другие) рассмотрели ...

Пожалуйста, знайте, что я также видел много-много ситуаций, когда состояние WiFi.status() было неправильным.
Так что, возможно, в основных библиотеках теперь есть исправления, и, скорее всего, я тоже где-то испортил все попытки заставить Wi-Fi работать стабильно.
Эту отладку было очень сложно выполнить, так как я не мог сам воспроизвести эти проблемы и должен был действовать в соответствии с отчетами других пользователей.
В последнее время у меня есть модуль, который также плохо себя ведет в отношении WiFi, так что это мой любимый тестовый модуль WiFi. Но это также может быть признаком того, что проблема усугубится, когда некоторые детали просто не соответствуют спецификации. Например, источник питания или отсутствие разделительных конденсаторов, (слишком) тонкие дорожки на печатной плате, меньшее экранирование и т. Д.

конечно, не то чтобы я исключаю HW-проблемы. Но у меня работает ~ 40 узлов со всеми разными типами источников питания, разными платами, брендами и т. Д., И в какой-то момент большинство из них сталкивается с проблемами подключения ... особенно со слабым покрытием Wi-Fi или большим количеством GPIO используется ..

И в настоящее время у меня есть немного времени на отладку, и я все еще нахожу это очень интересным и сложным;) Сейчас я даже начинаю понимать, как работает вся последовательность подключения, проверки, отключения и так далее;)

Так что, если для вас это нормально, я буду продолжать копать глубже в этих проблемах с подключением .... вы же босс ...

Продолжайте копать :)
Я действительно хочу освободиться от всех тех проблем с отключением, которые практически невозможно воспроизвести.
Они уже заняли слишком много времени, и было бы здорово, если бы они были исправлены.

Я получаю около 4-24 часов безотказной работы, а затем в среднем 2-10 часов простоя.
Во время простоя узел продолжает работать, но нет подключения к Wi-Fi.

Точка доступа (MikroTik) показывает:

18:16:15 wireless,info 80:xx:xx:xx:xx:xx<strong i="8">@iotnet</strong>: connected, signal strength -62 
18:16:20 wireless,info 80:xx:xx:xx:xx:xx<strong i="9">@iotnet</strong>: disconnected, unicast key exchange timeout 
18:17:31 wireless,info 80:xx:xx:xx:xx:xx<strong i="10">@iotnet</strong>: connected, signal strength -60 
18:17:36 wireless,info 80:xx:xx:xx:xx:xx<strong i="11">@iotnet</strong>: disconnected, unicast key exchange timeout 

ESP Easy | Информация |
----- | ----- |
Сборка: ⋄ | 20103 - Мега |
Библиотеки: ⋄ | ESP82xx Core 2_4_2, NONOS SDK 2.2.1 (cfd48f3), LWIP: 2.0.3 Поддержка PUYA |
Версия GIT: ⋄ | mega-20190110 |
Плагины: ⋄ | 7 [Normal] [Sonoff POW R1 / R2] |
Время сборки: ⋄ | 10 января 2019 03: 21: 19 |
Двоичное имя файла: ⋄ | ESP_Easy_mega-20190110_hard_SONOFF_POW_4M.bin |

Это не было проблемой в более старой версии (когда я все еще мог использовать канал 14 и иметь свою сеть с скрытым ssid).

Канал WiFi у вас фиксированный или он переменный?
Я читал на странице устранения неполадок Tasmota, и они настоятельно рекомендуют исправить канал WiFi.
Если канал 14 не используется, то, возможно, что-то в региональных настройках где-то изменилось, поскольку во всех странах разрешены только каналы 1-11.
Также каналы 1, 6 и 11 фактически являются единственными каналами, которые можно использовать без помех от других каналов.

работают только каналы 1-10, а не 11. См. это: https://github.com/letscontrolit/ESPEasy/issues/1337#issuecomment -394118989

Канал вифи фиксированный, конечно.

Любой канал может иметь помехи от других каналов, без возможности их контролировать. Черт, могут даже быть помехи от одного и того же канала.

Кстати, что касается проблемы, с которой я столкнулся - индикатор состояния Wi-Fi (перевернутый GPIO13) обычно горит синим цветом, но когда устройство отключено, оно идет по шаблону 0,0,0,0,0,1,2,3, 4,5,6,7,8,9,0,0,0,0,0,0,0,0,1,2,3,4,5,6,7,8,9,0,0, 0,0,0, ... яркости.

Фиксированный IP и DCS, но каналы никогда не менялись раньше.

Фон: Гийс Нурландер [mailto: [email protected]]
Гесендет: Фрайтаг, 11. янв.2019 21:47
An: Letcontrolit / ESPEasy
Копия: подписан
Betreff: Re: [Let'scontrolit / ESPEasy] [BUG] [Стабильность WiFi] Исключение ESP 3/29 при отключении уровня 2 (№ 1987)

Канал WiFi у вас фиксированный или он переменный?
Я читал на странице устранения неполадок Tasmota, и они настоятельно рекомендуют исправить канал WiFi.
Если канал 14 не используется, то, возможно, что-то в региональных настройках где-то изменилось, поскольку во всех странах разрешены только каналы 1-11.
Также каналы 1, 6 и 11 фактически являются единственными каналами, которые можно использовать без помех от других каналов.
-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это электронное письмо напрямую, просмотрите его на GitHub https://github.com/letscontrolit/ESPEasy/issues/1987#issuecomment-453651579 или отключите https://github.com/notifications/unsubscribe-auth/AomgSxPjVKWrp0MSQTCPBESKxFqaPVt90 . https://github.com/notifications/beacon/AomgS_fhHQnmg1AdpX11mVL9yNra8S_kks5vCPgxgaJpZM4YDivP.gif

Mikrotik дает большую мощность, но даже настройки по умолчанию для Wi-Fi неправильные.

• Убедитесь, что у вас нет в настройках безопасности tkip и включите только шифрование aes ccm
• Введите группу ключей Обновите, например, 30 минут или 1 час
• в каналах ширина канала 20Mhz и, по моему мнению, dich B band и идти только для G / N
• Канал расширения отключен
• Только отключение PMKID (рекомендуется, если вы в истерике по поводу безопасности), кажется, делает Esp очень неприятным
• Добавьте свою страну в настройки Wi-Fi (или посмотрите, какая у вас максимальная мощность для вашей точки доступа, и уменьшите мощность передачи на 3). Это очень часто повышает производительность Wi-Fi (я знаю, что интуитивно понятно)

Обычно у меня нет отключений (кроме случаев, когда у меня была эта штука PMKID)

В любом случае было бы полезно опубликовать настройки вашей точки доступа :-)

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

Обновление группового ключа связано только с групповым ключом, а не с одноадресным ключом, в котором также заключается проблема, но я понизил этот параметр для целей эксперимента.

@ 0ki Cool не знала, где ты специалист по RouterOS!

Я пришел к выводу, что это явно ошибка в программе ESPEasy. Вы можете увидеть проблемное поведение справа, которое соответствует отключению RouterOS от неправильно работающего клиента слева. Радиоспектр, как видите, ясен.

К сожалению, сейчас у меня нет времени углубляться в кодовую базу ESPEasy, но я надеюсь, что это сравнение плохого и хорошего общения будет полезно.
Условные обозначения: __red - точка доступа | синий - espeasy | зеленый - другое устройство в моей сети iot__

Я считаю, что ESP_easy по какой-то причине решает переключиться в режим AP после получения ответа Assoc (кадр 380 слева) и не продолжать четырехстороннее рукопожатие. Обратите внимание на изменение mac-адреса espeasy - первый октет изменяется с 80 на 82.

@ 0ki

Я пришел к выводу, что это явно ошибка в программе ESPEasy.

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

Какой именно файл вы имеете в виду под «этим кодом»? Если вы укажете на файл или два, я могу взглянуть на них.

В противном случае - поскольку теперь вы видите точный момент, когда это происходит, я надеюсь, вы сможете взглянуть на это поближе.

Поскольку я копаюсь в этой проблеме (около 2 месяцев), я больше не совсем уверен, что это сам код ESPEasy. подробнее о взаимодействии между ESPEasy и ядром / библиотекой WiFi ... Мои отладки / журналы показывают, что "Disconnect" всегда происходит после обмена / смены группового ключа. НО обратный вызов вызывается только после тайм-аута смены ключей и впоследствии после сбоя аутентификации ... Итак, я предполагаю, что ESPEasy не оставляет достаточно времени процессора для ядра, чтобы фактически выполнить смену ключей ... до сих пор я не делал этого. Однако я не нашел способа узнать, находится ли узел в этом узле с заменой ключа или в режиме повторной аутентификации, и, следовательно, он может добавить достаточно вызовов delay() чтобы повторная аутентификация была успешной ...

Чтобы помочь определить проблему по времени - она ​​работала нормально:

Build   20100 - Mega (core 2_3_0)
GIT version mega-20180224
Plugins 48 [Normal]
Build Md5   719b94a4d6bc257b86916e4989eed3a0
Md5 check   passed.
Build time  Feb 24 2018 03:03:12

И под «ок» я имею в виду, что не только не было отключения, но и подключение к скрытой точке доступа на канале 14 не было проблемой.

@ clumsy-stefan, я полностью поддерживаю выявление проблемы, из-за которой он отключается, но, честно говоря, может быть ряд причин, по которым связь с Wi-Fi может упасть, конечно, обмен групповыми ключами не должен быть одним из их.

Более насущная проблема - почему он не может повторно подключиться после отключения. Это не может быть проблемой времени, так как я очень стараюсь ответить сообщением 2 4way HS.

Я думаю, проблема в том, что вы отключаетесь только ПОСЛЕ того, как произошел сбой обмена ключами ... так что вы никогда не будете сейчас, когда обмен действительно начинается, вот где вам нужно будет уделить больше времени ядру ...

в журналах вы можете видеть, что ESPEasy довольно долго думает, что он все еще подключен, даже если это не так (даже пинг до узла не удается), но узел все еще пытается отправить данные (и, очевидно, тогда соединение не удается) ...

вторая проблема, с которой я полностью согласен, заключается в том, что, даже если происходит отключение, почему он не может повторно подключиться с совершенно новой последовательностью подключения ... возможно, модуль или ядро ​​застряли в каком-то странном состоянии?

РЕДАКТИРОВАТЬ: PS: 4way HS не всегда выходит из строя (я делаю это каждые 10 минут), поэтому, похоже, это комбинация состояния / занятости ESPEasy и времени, когда происходит HS ..

Что я могу сделать, так это попытаться полностью отключить Wi-Fi (также выключить модем) и начать полное новое переподключение при неожиданном отключении.
Не уверен, было ли это в этой теме, но в одной из этих проблем кто-то ответил твитом кого-то из Шелли, который упомянул, что им пришлось полностью перезапустить стек Wi-Fi после отключения.

@ TD-er это тоже то, что я вставил в свою последнюю версию. внутри processDisconnect() я добавил setWifiMode(WIFI_OFF); не уверен, если этого достаточно ... в настоящее время он работает на некоторых тестовых узлах (примерно с 1 часа) ...

@ TD-er, это отличная идея. нажмите на выпуск git, и я прошью свои вещи!

Я только начал читать часть кодовой базы 5 минут назад, так что это может быть неактуально, но: Также убедитесь, что wifi_connect_attempt установлен на 0 в этот момент.

хм ... добавление некоторого количества delay(0) в backgroundtasks() после каждого вызова подпрограммы, похоже, немного стабилизирует первую проблему (4way-HS). Не уверен, что это совпадение ...
@ TD-er может быть так, что backgroundtasks() в какой-то момент блокирует выполнение?

Вообще говоря: добавление delay(0) во всевозможные места, где временная статистика показывает длительное время обработки, похоже, значительно улучшает обработку 4way-HS. У меня сейчас больше сторожевых псов SW / HW, чем проблем с заменой ключей (но все еще есть) ... симптоматично, поэтому я бы сказал, что это действительно связано с частью ядра / Wi-Fi, не получающей достаточного количества циклов, чтобы на самом деле выполнять (довольно быстро) такие вещи, как замена ключей и точка доступа устает ждать ответа ...

Я также вижу, что иногда client.connect() или sendData() могут занять довольно много времени (до 2 секунд). В некоторой документации я обнаружил, что если что-то занимает более 50 мс, вы должны вызвать delay(0) между ними .... но вы не можете разделить эти вызовы, поскольку они выполняются библиотекой ...

В ядре есть еще один обратный вызов onStationModeAuthModeChanged . Вероятно, на это стоит обратить внимание, так как этот, вероятно, срабатывает до того, как произойдет фактическое отключение. но это очень мало задокументировано ... У кого-нибудь есть опыт с этим?

РЕДАКТИРОВАТЬ: это похоже на совпадение / состояние гонки с некоторыми другими делами, которые выполняются в то время, когда AP запрашивает смену ключей .... но снова просто наблюдения ...

Я не знаю, как часто эти запросы, отправленные AP, передаются повторно.
Обычно маяковый радиосигнал от точки доступа отправляется каждые 102,4 мс. Если для некоторых задач требуется больше, ESP пропускает один из таких сигнальных кадров. Так что я не уверен, насколько это плохо.
Я знаю, что запросы ARP иногда пропускаются, что приводит к проблемам, из-за которых коммутатор больше не знает, как маршрутизировать пакеты на этот MAC-адрес и, таким образом, делает ESP недоступным, хотя он все еще может отправлять данные.

недостающие кадры маяка ничего. ему даже не нужны кадры маяка, так как он в любом случае должен активно искать мою скрытую сеть.

Я не специалист в WiFi.
Как я понял, интервал маяка - это единственный, в некоторой степени, гарантированный момент, когда ESP пытается прослушивать Wi-Fi, а в промежутках между ними он будет пытаться спать как можно дольше.

И, как я понял, единственная разница между «скрытыми» и «не скрытыми» сетями заключается в том, что SSID не транслируется. Фактически, это соединение только на основе BSSID (MAC-адреса AP).
Это также то, что делает ESP при подключении к (не скрытым) сетям Wi-Fi, с той лишь разницей, что он выполнит сканирование раньше и попытается найти BSSID, который имеет SSID, который соответствует данному.
При выполнении автоматического переподключения он сначала попробует последнюю известную комбинацию каналов BSSID + без выполнения сканирования. Другими словами, он отличается только при подключении.

Итак, насколько мне известно, пока есть подключение к сети, он также будет прослушивать кадры маяка.

Я не специалист в WiFi.
Как я понял, интервал маяка - это единственный, в некоторой степени, гарантированный момент, когда ESP пытается прослушивать Wi-Fi, а в промежутках между ними он будет пытаться спать как можно дольше.

И как я понял, единственная разница между «скрытыми» сетями и «не скрытыми» сетями ..........

О, это напоминает мне кое-что, что может быть очень важным. Я запускаю свои ESP в скрытом SSID
Между прочим, на моих узлах все еще нет отключений или перезагрузок (пытаюсь обновить групповые ключи за 5 минут)

Один из моих узлов был перезагружен 5 декабря из-за отключения электроэнергии.

Это из того:

Единица: | 5
- | -
Местное время: | 2019-01-15 23:27:32
Время работы: | 41 день 12 часов 46 минут
Нагрузка: | 15,80% (LC = 9135)
Бесплатная память: | 12160 (5360 - sendContentBlocking)
Бесплатный стек: | 3552 (1520 - SensorSendTask)
Загрузка: | Холодная загрузка (0)
Причина сброса: | Внешняя система
Сеть ❔
Wi-Fi: | 802.11N (RSSI -67 дБ)
Конфигурация IP: | DHCP
IP / подсеть: | 192.168.1.89 / 255.255.255.0
GW: | 192.168.1.1
Клиентский IP: | 192.168.1.67
DNS: | 192.168.1.1 / 0.0.0.0
Допустимый диапазон IP-адресов: | Все разрешено
STA MAC: | 5C: CF: 7F: B1: 3F: 12
AP MAC: | 5E: CF: 7F: B1: 3F: 12
SSID: | Lurch4 (34: 31: C4: B1: 8D: C7)
Канал: | 11
Подключено: | 20х04м
Причина последнего отключения: | (202) Ошибка аутентификации
Номер переподключается: | 61
Прошивка
Сборка: ⋄ | 20102 - Мега
Библиотеки: ⋄ | ESP82xx Core 2_4_2, NONOS SDK 2.2.1 (cfd48f3), LWIP: 2.0.3 Поддержка PUYA
Версия GIT: ⋄ | мега-20181109
Плагины: ⋄ | 46 [Нормальный]
Сборка Md5: | 47f19d99d0c3f083314b45668b1f5c
Md5 проверка: | прошло.
Время сборки: ⋄ | 9 ноя 2018 03:23:22
Двоичное имя файла: ⋄ | ESP_Easy_mega-20181109_normal_ESP8266_4096.bin

Как видите, в среднем более одного отключения в день. Он подключен к AVM Fritzbox 1750E.

Я думаю, что кадры маяка не так критичны ... Мне до сих пор не понятно, почему после отключения обычная последовательность WiFi.begin() всегда дает сбой с '(2) Auth expire' .

Единственным признаком является то, что загрузка ЦП в этот момент всегда показывает 100% и намекает на то, что ядру просто не хватает времени, чтобы выполнить рукопожатие ...

Я предполагаю, что что-то не так с основными библиотеками (LWIP, Arduino или ESP), и мы должны сбросить Wi-Fi.
Таким образом выключите Wi-Fi и начните все сначала. Также можно подождать между этими шагами, чтобы убедиться, что буферы опустошены или, по крайней мере, очищены, а невыполненные запросы активно отменяются.

@ TD-er, можешь ли ты продвинуть это изменение, чтобы я мог посмотреть, работает ли оно?

Изменения обсуждались в последних 2 сообщениях?
Он еще не реализован, но сегодня вечером я могу попробовать его закодировать и сделать тестовую сборку.

Ага, сброс Wi-Fi.

@ TD-er написал:

Таким образом выключите Wi-Fi и начните все сначала. Также можно подождать между этими шагами, чтобы убедиться, что буферы опустошены или, по крайней мере, очищены, а невыполненные запросы активно отменяются.

Не уверен в очистке ... так как я удалил все вызовы client.flush() перед client.stop() Также казалось, что отключение происходит реже. Читая некоторую документацию, я увидел, что при сбросе очищаются все входные буферы (tcp), поэтому теоретически может случиться так, что ответы будут потеряны ...

Просто добавив свой 2c, у меня есть несколько точек доступа Mikrotik, с несколькими sonoff, работающими с espurna, и несколькими NodeMCU, работающими с ESPEasy. Мне пришлось добавить дополнительную точку доступа для устройств ESP, потому что во время периода высокого трафика в моей сети, например резервного копирования, я терял свои устройства ESP. Я думаю, это было связано с мощностью сигнала WiFi и трафиком. После добавления дополнительной точки доступа я не помню, чтобы снова видел эту проблему.

Но у моих устройств NodeMCU и ESPEasy есть некоторые отключения. Я собираюсь настроить монитор пинга netdata для устройств и посмотреть, смогу ли я выяснить, когда, как и почему это может происходить, и посмотрю, верну ли я некоторую информацию.

Еще одно замечание: у меня нет более 40 устройств, таких как @ clumsy-stefan, только около 5 пользователей и их мобильные устройства и странное интеллектуальное устройство, такое как телевизор, но может быть, либо устройство Mikrotik перегружено, либо сеть WiFi RF насыщена ?

Я хотел бы иметь способ увидеть количество радиочастотного шума. У меня есть приложение (WiFi Analyzer), которое показывает количество точек доступа и их распределение по каналам WiFi. Я использовал этот инструмент, чтобы настроить свои каналы WiFi для разных точек доступа WiFi.

Но не могу точно сказать, могут ли быть другие радиочастотные помехи.

Что касается идеи перегруженного устройства Mikrotik, я использую MikroTik 951UI-2HND в качестве основного маршрутизатора и MikroTik RB9412nD hAP lite в качестве точки доступа ESP.

Интересно, полезна ли эта информация каким-либо образом?

@LeeNX спасибо за подсказки. мои узлы распределены по 3 точкам доступа, а RF несколько сбалансирован (максимум 20 клиентов на точку доступа или около того), так что помехи как можно меньше (конечно, их не может быть ...). Поэтому я не думаю, что МТ перегружены (я работаю в компании, предоставляющей магистральные сети и WLAN для профессиональных мероприятий и т. Д., Поэтому у меня есть довольно глубокие тесты инфраструктуры), но я согласен, что перегруженное эфирное время может быть проблемой ... однако, даже если это так, узел никогда не сможет повторно подключиться> 250 раз после отключения, а затем после перезагрузки он немедленно повторно подключается, я думаю, не может быть проблемой эфирного времени ... кроме того, я не не вижу этого на любом другом устройстве ...
так что я все еще думаю, что это какое-то совпадение или состояние гонки между состоянием внутреннего чипа Wi-Fi, количеством процессорного времени, которое получает ядро ​​Wi-Fi, и тем, какие другие задачи выполняются в части ESPEasy ...

@ clumsy-stefan Я согласен с твоим пониманием. Я просто хотел указать, что использование маленькой точки доступа Mikrotik с 40+ узлами могло быть ограничено процессором Mikrotik или оперативной памятью, но это не похоже на проблему.

Мне интересно, можно ли развернуть устройство ESP32 и NodeMCU ни с чем, кроме базового ядра ESPEasy, и позволить ему работать, чтобы мы могли протестировать процессор ESP и никакое другое влияние плагина. Посмотрите, что я могу развернуть, и проверьте пинг netdata.

Если это даст нам какую-либо полезную информацию, я сообщу.

Спасибо ребята!!!

У меня здесь почти ничего не работает узел (IR RX / TX), и он работает неделями без проблем.
Другой узел, время работы которого превышает 40 дней, работает под управлением Domoticz MQTT и BME280 + MH-Z19 CO2.
Таким образом, это, вероятно, также будет зависеть от того, какой плагин работает и как часто, и, возможно, также, если интервал чтения всегда соответствует интервалу чтения других плагинов.

Я уже установил некоторые периодические вызовы функций (10 / сек, 1 / сек и 30 сек) с начальным смещением в планировщике, чтобы они продолжали работать как можно чаще в разных вызовах цикла.

Возможно, мне также следует добавить какое-нибудь событие, управляемое таймером прерывания, как это делает Tasker (или просто использовать Tasker вместо написанного мной планировщика) и установить одну задачу с интервалом в 10 мсек для задержки запуска (0).
Единственное, это может прервать другие передачи GPIO и, таким образом, нарушить показания датчика.

это, вероятно, решит проблему 4way-HS, но я думаю, не проблема повторного подключения ... это все еще самая странная ... У меня только что мой тестовый узел снова вышел из строя в течение 12 часов, пытаясь повторно подключиться к AP более 300 раз без успех. после (мягкой) перезагрузки он мгновенно переподключился (перезагрузка + переподключение заняло около 5 секунд) ...

Я только что обнаружил эту проблему, которая выглядит очень связанной с тем, что мы здесь видим:
https://github.com/esp8266/Arduino/issues/5527

выглядит похоже, да ... но вызов Wi-Fi OFF, похоже, не меняет его (пробовал), в настоящее время я пытаюсь с WiFi.setOutputPower(0) перед вызовом WiFi.begin() как предлагается здесь
https://github.com/esp8266/Arduino/issues/2235
и тут
https://github.com/esp8266/Arduino/issues/2186#issuecomment -233853152
все еще жду, чтобы это случилось, сейчас тяжело ...

это похоже, но это не то же самое. Фактически, в нашем случае перезагрузка AP решает проблему, в проблеме, опубликованной Gijs, перезагрузка AP не решает проблему.

@ giig1967g перезагрузка AP для меня не решает! только перезагрузка узла заставляет его снова подключаться (хотя в моей среде) ...

@ giig1967g В проблеме, упомянутой https://github.com/esp8266/Arduino/issues/2235#issuecomment -248851270

Так что, похоже, здесь есть несколько проблем.

@ неуклюжий-Стефан
Ах хорошо. А в моем случае только с Микротиком ... :(
@ TD-er
возможно, вам стоит спросить, какую марку / модель точки доступа они используют ...

@ giig1967g У меня также было несколько узлов, которые были недоступны, но интервал этих событий был намного больше 10 дней, поэтому немного сложно сказать, связано ли это с одной из этих проблем.
Около половины моих узлов теперь подключены к Mikrotik, а другая половина подключена к Fritzbox 1750E.

@ giig1967g У меня также есть только MT ... и, похоже, это чаще случается с узлами с более слабым сигналом и узлами с использованием GPIO (в частности, PCF) ...

Я хотел бы иметь способ увидеть количество радиочастотного шума. У меня есть приложение (WiFi Analyzer), которое показывает количество точек доступа и их распределение по каналам WiFi. Я использовал этот инструмент, чтобы настроить свои каналы WiFi для разных точек доступа WiFi.

Но не могу точно сказать, могут ли быть другие радиочастотные помехи.

Вы можете сделать /interface wireless registration-table print interval=1 на своем mikrotik, чтобы увидеть snr.

к сожалению, WiFi.setOutputPower(0) тоже не помогло ... после почти 6 часов бесперебойной работы (без каких-либо изменений в инфраструктуре Wi-Fi, внезапно он снова попадает в тупик (см. последовательный вывод ниже), из которого он никогда не восстанавливается, кроме случаев, когда по совпадению включается SW или HW WDT ...

это происходит только после «тайм-аута обновления группового ключа» или «неудачного четырехстороннего рукопожатия». если я отключу узел от точки доступа вручную, он также получит "срок действия аутентификации", но может мгновенно подключиться заново ...

последовательный выход (тогда нагрузка не достигает 100%) ...

20457441 : WIFI : Disconnected! Reason: '(16) Group key update timeout' Connected for 2h19m
20457593 : WIFI : Connecting clumsy_ap2 attempt #0
20458607 : WIFI : Not configured in Station Mode!!: clumsy_ap2
20459707 : EVENT: WiFi#Disconnected
20459763 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 2012 ms
20470762 : SYS  : 31.00,20048.00,66.70,341.00
20470766 : EVENT: sysinfo#rssi=31.00
20470824 : EVENT: sysinfo#mem=20048.00
20470882 : EVENT: sysinfo#load=66.70
20470940 : EVENT: sysinfo#uptime=341.00
20472658 : EVENT: Clock#Time=Thu,14:22
20473264 : WD   : Uptime 341 ConnectFailures 22 FreeMem 20040 WiFiStatus 0
20477609 : WIFI : Connecting clumsy_ap2 attempt #1
20478135 : WIFI : Not configured in Station Mode!!: clumsy_ap2
20482577 : EVENT: WiFi#Disconnected
20482635 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 4771 ms
20503270 : WD   : Uptime 342 ConnectFailures 22 FreeMem 18440 WiFiStatus 0
20505709 : WIFI : Connecting clumsy_ap2 attempt #2
20506235 : WIFI : Not configured in Station Mode!!: clumsy_ap2
20509784 : EVENT: WiFi#Disconnected
20509845 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 3879 ms
20530897 : SYS  : 31.00,16248.00,100.00,342.00
20530902 : EVENT: sysinfo#rssi=31.00
20530963 : EVENT: sysinfo#mem=16248.00
20531025 : EVENT: sysinfo#load=100.00
20531087 : EVENT: sysinfo#uptime=342.00
20532688 : EVENT: Clock#Time=Thu,14:23
20533158 : WD   : Uptime 342 ConnectFailures 22 FreeMem 16240 WiFiStatus 0
20533716 : WIFI : Connecting clumsy_ap2 attempt #3
20534242 : WIFI : Not configured in Station Mode!!: clumsy_ap2
20537788 : EVENT: WiFi#Disconnected
20537851 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 3865 ms

просто небольшое замечание: добавление wifi_set_phy_mode(PHY_MODE_11G); и принудительное переключение узла в режим 802.11g кажется, по крайней мере, обходным путем. У меня не было перезагрузки какого-либо блока с нескольких часов, а также один или два раза блок, восстановленный из проблемы тайм-аута группового ключа выше ...
вероятно связано с

• ESP8266 SoftAP поддерживает только 802.11b / g.

что отмечено в документах ...

Я обновлю позже / завтра, если он будет стабильным ...

Как уже отмечалось (несколько раз) кем-то другим, чувствительность также следует повысить, переключившись на 802.11G.
Моя цель против этого (была?) В том, что у большинства точек доступа возникают проблемы при переключении между N, G и B.
У вас смешанные клиенты? (G и N) активны на одной точке доступа?

Я использую разные режимы на всех Mikrotik. B / G / N / AC смешанный, также оба диапазона 2/5 ГГц, включая определенные виртуальные точки доступа ... Разные клиенты подключаются в разных режимах к одной точке доступа без проблем (кроме esp8266).

хорошие новости (по крайней мере, для меня) ... мои узлы работали последние 12 часов без отключений / перезагрузок / зависаний!

принуждение узла к 802.11g, кажется, работает гладко вместе с AP MikroTik. по крайней мере, это простой обходной путь (если вам не нужна дополнительная скорость 802.11n).

если кто-то хочет проверить себя, просто добавьте в ESPEasyWifi.ino около строки 644 в функции tryConnectWiFi() следующую строку (после setupStaticIPconfig(); ):
WiFi.setPhyMode(WIFI_PHY_MODE_11G);

Я могу только догадываться, что проблема возникает из-за того, что режим SoftAP не поддерживает 802.11n, а узел подключен в режиме N, ядро ​​каким-то образом "запутывается" ... но я думаю, это проблема, которую следует поднять с основными людьми. ..

Для ESPEasy это можно сделать настраиваемым, я полагаю (@ TD-er?), Чтобы на странице конфигурации можно было выбрать, в каком режиме ESP должен работать (B / G / N) ...

Да, я добавлю опцию выбора в расширенных настройках.
Я забыл, кто спросил об этом первым, но посмотрю и укажу и на него в коммите;)

идеальный!! Мне не нужна заслуга, мне просто нужно, чтобы она работала;) так что не стесняйтесь посвятить ее ему !! 😄

Во время отладки я обнаружил некоторые другие мелочи, которые я бы предложил изменить (например, вызов delay() безоговорочно после вызовов плагина, некоторые дополнительные {} и некоторые дополнения к выходным данным журнала. Должен ли я сделать PR для эти ASPIT или вы хотели бы оставить его как есть (я думаю, что это не важные изменения, просто некоторые незначительные улучшения, вероятно)?

Пожалуйста, сделайте пиар.
По крайней мере, это поможет в обсуждении и отслеживании ваших выводов.
Также было бы полезно добавить комментарии к тому, что вы проверили.

Для справки № 2012
Все кредиты разработчику. команда!

Включает ли этот патч идею WiFi.setOutputPower (0)?

Я провожу эксперимент уже 7 дней.
узел мега-20180224 - нулевая перезагрузка
узел мега-20190110 - 35 перезагрузок; 9 из них сегодня.

Я оставил соответствующую строку в коде, но закомментировал ее. Поэтому вам нужно удалить // (примерно строку 644) в ESPEasyWiFi.ino и перекомпилировать его!

@oki извините, я только что увидел, что неправильно прочитал ваш вопрос ... Нет, это не включено, так как я не видел разницы при установке мощности на 0 перед повторным подключением ... Так что я снова отказался от этого!

Я провожу эксперимент уже 7 дней.
узел мега-20180224 - нулевая перезагрузка
узел мега-20190110 - 35 перезагрузок; 9 из них сегодня.

Это эффективное сравнение:

• ядро 2.3.0 без Wi-Fi на основе событий
• ядро 2.4.2 с Wi-Fi на основе событий.

хорошие новости (по крайней мере, для меня) ... мои узлы работали последние 12 часов без отключений / перезагрузок / зависаний!

принуждение узла к 802.11g, кажется, работает гладко вместе с AP MikroTik. по крайней мере, это простой обходной путь (если вам не нужна дополнительная скорость 802.11n).

Для тестирования я сделал наоборот.
Я установил свой Mikrotik только в N-режим, и что ж ... все ESP работают с 12 часов без единой перезагрузки.

хороший и действительный подход! К сожалению, я не могу этого сделать, поскольку у меня есть несколько клиентов без возможности N ...

Просто отключите режим B и включите только G / N. Вам лучше без режима B. Если у вас нет старых телефонов или (обычно) сканеров штрих-кода Wi-Fi 10-летней давности, которые поддерживают только режим B и скорости.

Дополнительная чувствительность антенны в режиме B также не будет играть существенной роли в дальности. Режим B просто съедает эфирное время. Буквально нет недостатка в неиспользовании режима B и недостатка в использовании режима N вместо G. Режим N имеет даже лучший диапазон, чем B и G.

@ jimmys01, вы правы, режим B, вероятно, больше нигде не используется ... но я не могу использовать только N ... поэтому было бы нужно проверить, что происходит в режиме G / N, если узлы остаются стабильными и могут повторно подключиться в случае тайм-аута 4way HS.

г / п для меня нестабильно.

Означает ли это, что esp8266 сталкивается с проблемами каждый раз при переходе между режимами (B / G / N)?

Означает ли это, что esp8266 сталкивается с проблемами каждый раз при переходе между режимами (B / G / N)?

Скорее всего.
Я видел много проблем с некоторыми устройствами (не с ESP), поддерживающими только режим G.
Если вы используете их вместе с N устройствами, они могут оказаться недоступными.
Печально известны HomeWizard и некоторые WiFi-камеры.

С этой новой версией mega-20190121 ESP кажется более стабильным, до сих пор у меня не было проблем с падением / Wlan.
Но теперь я больше не могу выключить OLED (framedPlugin). Когда я отправляю OLEDFRAMEDCMD, он выключает дисплей на очень короткое время, а затем снова включается.
Я провел параллельный тест со старой версией (с 2018 года), дисплей реагирует должным образом.

Только что опробовал mega-20190121 и стабильность WiFi такая же. Он вылетает примерно через час после запуска.

@ TD-er, как вы думаете, вы могли бы выпустить версию с обсуждаемым изменением, чтобы я мог ее протестировать?

быстрое обновление: после установки исправления режима на 802.11g у меня больше нет зависаний, перезагрузок и т. д.! хотя точки доступа работают в смешанном режиме g / n ... поэтому я бы также проголосовал за патч, который делает настраиваемый режим Wi-Fi на esp!

Надеюсь на патч скоро тоже 😉

Я только что добавил фиксацию для выбора только B / G.
Он еще не работает на ESP32, поэтому я отключил возможность выбора его для ESP32.
Я также добавил возможность отката, чтобы иметь возможность снова подключиться, если точка доступа не разрешает только B / G.

@ TD-er Я имею в виду это изменение:

Я предполагаю, что что-то не так с основными библиотеками (LWIP, Arduino или ESP), и мы должны сбросить Wi-Fi.
Таким образом выключите Wi-Fi и начните все сначала. Также можно подождать между этими шагами, чтобы убедиться, что буферы опустошены или, по крайней мере, очищены, а невыполненные запросы активно отменяются.

Изменения обсуждались в последних 2 сообщениях?
Он еще не реализован, но сегодня вечером я могу попробовать его закодировать и сделать тестовую сборку.

@oki Я попробовал оба варианта, установив выходную мощность на 0 и активно отключая / повторно подключаясь при возникновении проблемы. обе версии не помогли сбросить / повторно подключиться к AP ... (в моей среде) ... подробнее см. выше ...
единственное, что сделало его стабильным, - это использование N-Mode.

Я это прекрасно знаю. Надеюсь на скорый патч, чтобы продолжить отладку.

@ 0ki Я могу сделать для вас тестовую сборку, используя этот последний коммит.
Или еще хотите потестить с отключением WiFi?

И если да, то какие варианты вам нужны / нужны? WiFi выключить / включить и перезапустить все службы?
Последняя часть (перезапуск служб) - это тоже одна вещь, на которую стоит внимательно посмотреть, поскольку я не совсем уверен, что все службы, использующие сокет, перезапускаются должным образом.
Это также может вызвать некоторые проблемы, я думаю, при воссоздании Wi-Fi-соединения.

Автоматическое полное выключение (а затем включение) передатчика Wi-Fi при обнаружении разъединения.

Я вижу, что вы добавили код. Какую версию я могу использовать, чтобы проверить это?

Не уверен, сделаю новую сборку для тестирования.
Это будет сделано за +/- 30 минут.

тестовая сборка
Он основан на том, что я объединил ранее сегодня, и PR # 2235, в котором есть изменения для подключения в режиме B / G.
Кажется, в этом PR есть проблемы с некоторыми плагинами, поэтому он еще не был объединен.

Благодаря! Прошил тестовую сборку.

Сейчас у меня следующие настройки:
Connection Failure Threshold: 0 Force WiFi B/G: NO Restart WiFi on lost conn.: YES

Как вы думаете, мне следует проверить что-то по-другому, учитывая, что у меня PLATFORMIO_ESP12E?
То есть я забыл, будет ли b / g работать на esp12e и какой именно порог сбоя соединения был.

Этот порог является всего лишь счетчиком для инициирования перезагрузки, если количество неудачных попыток подключения превышает это значение.
0 по умолчанию и означает, что перезагрузка не выполняется.

Я предполагаю, что установка значения 50 или 100 поможет вам перезагрузить его, когда он может оказаться в труднодоступном месте и попасть в какой-то цикл повторного подключения.

Даже с этой настройкой он все еще может показывать перезагрузки сторожевого таймера HW, как уже показали некоторые мои узлы.
Просто может быть труднее воспроизвести те, в которых активен режим B / G.

тестовая сборка
Он основан на том, что я объединил ранее сегодня, и PR # 2235, в котором есть изменения для подключения в режиме B / G.
Кажется, в этом PR есть проблемы с некоторыми плагинами, поэтому он еще не был объединен.

Спасибо за тестовую сборку.
Мой ранее самый нестабильный ESP12F теперь работает 59 часов без перезагрузки :)

РЕДАКТИРОВАТЬ: настройки:
Принудительно использовать WiFi B / G: ДА
Перезапустите WiFi при потере соединения: ДА

Я думаю, что я выделю этот коммит (B / G WiFi) в отдельный PR, чтобы его можно было объединить, прежде чем я исправлю остальную часть PR, в которой он теперь ожидает объединения.

Хорошая идея!

Мои предыдущие настройки RestartWifi = YES ничего полезного не сделали.

Теперь я перешел на

Connection Failure Threshold: 0
Force WiFi B/G: YES
Restart WiFi on lost conn.: NO

и он работал два дня без перезагрузки и даже без отключения. Удивительный. Не думаю, что я вообще откажусь от этой тестовой версии.

Через прибл. Через 100 часов модуль наконец-то сбросился. :(

Причина сброса: аппаратный сторожевой таймер

Однако это также может быть вызвано сложной конфигурацией (12 датчиков 1-Wire и сервер FHEM).

Вы также можете попробовать добавить этот патч: https://github.com/letscontrolit/ESPEasy/pull/2235/commit/9a05eaf828a737ae416ab11c8df8c4a5b03ceaf2
Возможно, это также поможет улучшить стабильность.
Он включен в эту тестовую сборку

Вы также можете попробовать добавить этот патч: 9a05eaf
Возможно, это также поможет улучшить стабильность.
Он включен в эту тестовую сборку

Благодаря!
Установил его на два совершенно разных настроенных блока и дадим обратную связь.

был запущен на одном из моих тестовых узлов, включая
https://github.com/letscontrolit/ESPEasy/commit/9a05eaf828a737ae416ab11c8df8c4a5b03ceaf, к сожалению, потребовалось всего около 2 часов, прежде чем снова столкнуться с проблемой тайм-аута группового ключа и не восстановить или когда-либо повторно подключиться к AP. При включенном "перезапуске Wi-Fi при потере соединения" и без принудительного включения B / G .... так что N все еще кажется проблемой ..
Так что для меня режим B / G пока единственный стабильно работающий вариант.

Можно ли вообще отказаться от поддержки N? Нужны ли нам преимущества N для такого простого устройства?

@ 0ki с "новой" опцией для принудительного включения режима B / G, встроенного в @ TD-er, он в основном отбрасывает N на программном уровне, вы не можете удалить его из основных библиотек, я полагаю ...

При перемещении этого параметра в основные настройки я рекомендую, чтобы этот параметр был включен по умолчанию.

Мы могли бы сделать это динамичным.
Если подключение невозможно, попробуйте еще раз с включенной опцией N.

Есть много настроек, в которых в AP проверяется только N. Таким образом, в этих средах вы не можете вернуться, если отключите поддержку N в ESPeasy.

Вы также можете попробовать добавить этот патч: 9a05eaf
Возможно, это также поможет улучшить стабильность.
Он включен в эту тестовую сборку

Благодаря!
Установил его на два совершенно разных настроенных блока и дадим обратную связь.

Пока один модуль перезапустился через 2 дня, другой - через 5 дней.
Оба показали «Сторожевой таймер оборудования» как причину сброса.
Оба модуля настроены на «Force WiFi B / G: Yes» и «Restart WiFi on lost conn .: Yes».
AP - это Mikrotik, настроенный только на B / G (время безотказной работы 49 дней).
Расстояние между точкой доступа и модулями прибл. 2 ... 3 мес.

Мне было интересно, почему мое предложение сделать его динамичным (вернуться к N только из настроек B / G) получило 2 голоса против.
Пожалуйста, объясните, почему это не очень хорошее предложение.

Мне было интересно, почему мое предложение сделать его динамичным (вернуться к N только из настроек B / G) получило 2 голоса против.
Пожалуйста, объясните, почему это не очень хорошее предложение.

На мой взгляд, если кто-то включит эту опцию, он уже отчаянно ищет большей стабильности и знает, что это значит для его настроек точки доступа.
Я предпочитаю статическое решение, потому что, когда я выбираю только вариант B / G, я абсолютно никогда не хочу оказаться в ситуации, когда я думаю, что он использует B / G, но опять же, нет.
Однако, поскольку мои узлы все равно перезагружаются (хотя и реже), я хотел бы получить реальное решение проблемы, связанной с новым ядром.

Я понимаю, но вы также должны понимать проблему, когда пользователи не знают, что делает параметр, и в конечном итоге получают недостижимые узлы.
Так что у него должен быть большой порог, прежде чем снова переключиться на поддержку N.
Например, откат поврежденных плагинов:
После 10 неудачных перезагрузок он отключит 1 плагин или контроллер, чтобы проверить, может ли перезагрузка пройти успешно.

Нечто подобное можно применить и к Wi-Fi-соединению.
После X неудачных попыток повторного подключения он разрешит подключение с разрешенным 802.11N.
Качество приема лучше для сетей в режиме G, поэтому, если вы установите X примерно на 10, очень маловероятно, что он подключится к N вместо G. Особенно, если вы сбрасываете этот счетчик каждый раз, когда пытаетесь выполнить его в режиме N.

Хм, последние несколько недель, когда для ESPeasy было меньше времени, я, по-видимому, запутался в моей памяти о том, что я планировал реализовать или что было реализовано.

Я просто посмотрел на код и обнаружил:

void setConnectionSpeed() {
  #ifdef ESP8266
  if (!Settings.ForceWiFi_bg_mode() || wifi_connect_attempt > 10) {
    WiFi.setPhyMode(WIFI_PHY_MODE_11N);
  } else {
    WiFi.setPhyMode(WIFI_PHY_MODE_11G);
  }
  #endif

Таким образом, очевидно, что это уже было реализовано, чтобы разрешить N только тогда, когда wifi_connect_attempt > 10.
Этот счетчик сбрасывается на 0 при успешной попытке подключения к Wi-Fi.

Это приемлемое решение?

Хм, последние несколько недель, когда для ESPeasy было меньше времени, я, по-видимому, запутался в моей памяти о том, что я планировал реализовать или что было реализовано.

Я просто посмотрел на код и обнаружил:

void setConnectionSpeed() {
  #ifdef ESP8266
  if (!Settings.ForceWiFi_bg_mode() || wifi_connect_attempt > 10) {
    WiFi.setPhyMode(WIFI_PHY_MODE_11N);
  } else {
    WiFi.setPhyMode(WIFI_PHY_MODE_11G);
  }
  #endif

Таким образом, очевидно, что это уже было реализовано, чтобы разрешить N только тогда, когда wifi_connect_attempt > 10.
Этот счетчик сбрасывается на 0 при успешной попытке подключения к Wi-Fi.

Это приемлемое решение?

Что ж ... я бы сказал да (надеюсь, что ошибка в 2.5.0 скоро будет обнаружена).

Отзыв только о настройке B / G.
Я только что установил тестовую прошивку на одном устройстве, которое перезагружалось каждые 20 минут. Раньше был подключен к N с -72dBi. Это должно было быть достаточно хорошим сигналом, чтобы не отключаться. Я использую точки доступа корпоративного уровня с возможностью приема -105 дБи. Так что снова он никогда не должен сбрасывать канал.

Через несколько часов с тестовой прошивкой и сброса пока не было.
Я буду продолжать работу и доложу.

PS: Согласен, что это как-то связано с N.
PSS: Я использую 20 узлов ESP-07, которые были обновлены до 4M. Отнимает много времени, но окупается при необходимости перепрошивки.

У меня более 120 узлов, работающих на GN (mega-20190202), без каких-либо проблем. Все они сообщают, что подключены к N

@ jimmys01 Сколько узлов подключено к одной
А какой у этой точки доступа? (Микротик?)

Почти все они подключаются к разным точкам доступа (по одной на номер в отеле). У них есть переключатель (датчик PIR), датчик температуры и влажности HTU, а также ИК-светодиоды.
Бренд AP - Mikrotik.
Настройки следующие:
Страна установлена
Канал управления: 20 МГц
Группа: GN
Канал расширения: отключен
Тип аутентификации: только WPA2 PSK
Шифрование: только aes ccm
Групповое шифрование: aes ccm
Обновление ключа Groyp: 00:01:00

Отзыв только о настройке B / G.
Я только что установил тестовую прошивку на одном устройстве, которое перезагружалось каждые 20 минут. Раньше был подключен к N с -72dBi. Это должно было быть достаточно хорошим сигналом, чтобы не отключаться. Я использую точки доступа корпоративного уровня с возможностью приема -105 дБи. Так что снова он никогда не должен сбрасывать канал.

Через несколько часов с тестовой прошивкой и сброса пока не было.
Я буду продолжать работу и доложу.

PS: Согласен, что это как-то связано с N.
PSS: Я использую 20 узлов ESP-07, которые были обновлены до 4M. Отнимает много времени, но окупается при необходимости перепрошивки.

К сожалению, устройство продолжает сбрасываться через случайное время. Что угодно в течении 1-4 часов.
Только B / G FW не решает мои проблемы

Мне было интересно, почему мое предложение сделать его динамичным (вернуться к N только из настроек B / G) получило 2 голоса против.
Пожалуйста, объясните, почему это не очень хорошее предложение.

Скажем, сам Wi-Fi отключается на час из-за внешних / экологических обстоятельств. Мой узел (узлы) переключается на N и снова становится очень нестабильным (мое приложение чувствительно к перезагрузкам - Wi-Fi не обязательно должен быть там 100% времени, но сам узел должен работать все время).

Мне нужна такая конфигурация для моих узлов, которая избегает нестабильности и никогда не подключается к N, что делает это для меня прямо сейчас.

При перемещении этого параметра в основные настройки я рекомендую, чтобы этот параметр был включен по умолчанию.

В качестве решения мы могли бы по умолчанию перевести это в резервный режим (B / G-затем-N) с возможностью переключения только на B / G или B / G / N.

Что касается фактического решения для 2.5.0, попробуйте следующее:

#include "esp_wifi.h"
esp_wifi_set_ps(WIFI_PS_NONE);

У меня более 120 узлов, работающих на GN (mega-20190202), без каких-либо проблем. Все они сообщают, что подключены к N

Как обновить 120+ узлов в приемлемые сроки?
".. никаких проблем ..." проверяли ли вы время безотказной работы каждого узла и что это такое?
Все остались прежними с момента последней предполагаемой перезагрузки?

Время безотказной работы считается днями, и все они имеют 0 повторных подключений. Уже несколько месяцев у меня никогда не было проблем с подключением, кроме случаев, когда я отключал PMKID на точках доступа. Вероятно, новое ядро ​​стало более требовательным к настройкам Wi-Fi, или я не знаю что .. Я также запускаю все те с блоками питания 2А. Мы планируем в следующем месяце развернуть еще 80 esp8266. Кстати, если @ TD-er вам нужен доступ, чтобы посмотреть на конкретную настройку, я с радостью предоставлю его вам. Я действительно хочу, чтобы ESPEasy процветала, он нам очень помог.

Изменить: @ chunter1 Я обновляю их с помощью пакетных скриптов

curl -# -o /dev/null --form update=@ESP_Easy.bin --max-time 40 --connect-timeout 20 --retry 1 http://x.x.x.x/update

@ jimmys01 Я недавно сам купил Mikrotik, чтобы иметь возможность тестировать.

И просто заметка о сборках ядра 2.5.0.
В предстоящие ночные сборки сборки 2.5.0 не включены, поскольку в ядре 2.5.0 есть ошибка, из-за которой веб-сервер перестает отвечать и дает сбой узла.
Как только это будет исправлено, снова появятся сборки ядра 2.5.0.
В последнюю ночную сборку включена альфа-версия ядра 2.6.0, которая по сути представляет собой последний код из github основной библиотеки, поэтому вы можете убедиться в этом сами.

Получил 2.6.0 с B / G, работающим только с 4 дней на двух модулях, и первый сделал перезагрузку.
Причиной сброса был обычный «аппаратный сторожевой таймер».
То, что я наблюдаю, поскольку активен только режим «B / G», - это время работы 3..5 дней до того, как произойдет сброс.

Возможно, также сравните количество отключений Wi-Fi, поскольку эти отключения, похоже, связаны с сбоями.

Оба модуля находятся в подвале, всего в 2..3 м от Mikrotik AP.
Я только что проверил второй модуль с той же версией FW, и он показывает 0 повторных подключений и время безотказной работы 4d02h (без перезагрузки с момента перепрошивки).
Я очень полагаю, что это другой модуль, который сделал сброс. также было 0 повторных подключений перед сбросом.

Что касается задач, настроенных на двух тестовых модулях:
В модуле, который выполнил сброс, настроено 12 датчиков DS18B20, которые каждые 120 с отправляют свое значение на сервер FHEM.
Модуль, который до сих пор не сбрасывался, имеет только два настроенных gpios, которые также отправляют свои значения каждые 120 секунд на один и тот же сервер FHEM.

Итак, AP (Mikrotik) такая же, расстояние (2..3мм) такое же, FHEM сервер такой же - просто модуль с 12 датчиками температуры однозначно перезагружается чаще, чем модуль с 2 gpios.

на моих узлах это происходит в основном, когда fhem слишком медленно реагирует или недоступен, потому что я определил максимальное количество повторных попыток 100, а затем узлы перезагружаются (что также показывает ручную перезагрузку).

на моих узлах это происходит в основном, когда fhem слишком медленно реагирует или недоступен, потому что я определил максимальное количество повторных попыток 100, а затем узлы перезагружаются (что также показывает ручную перезагрузку).

Зачем вашим узлам перезагружаться, если повторных попыток больше 100?
(Я установил 0 повторных попыток для тестирования)

инструменты -> расширенный -> порог сбоя подключения

чтобы убедиться, что если Wi-Fi на модулях по какой-то причине задыхается, то через некоторое время он перезагружается ...

Ах, с "повторными попытками" вы имеете в виду "Порог сбоя подключения:", а не "Максимальное количество попыток:" в настройках контроллера FHEM.
Я установил порог сбоя подключения на 0.

Кстати: впервые у меня был узел, который застрял в проблеме тайм-аута 4WHS, хотя был активен "только B / G" ... никогда этого не было до сих пор (самкомпилированный, ядро ​​2.5.0) .... Я буду следить за этим, если бы это было просто совпадением ...

Обратите внимание, что очень скоро появится ядро ​​2.5.1, которое вернет использованный SDK к SDK2.2.1, поскольку с SDK3.0.0 возникает множество проблем.
Это также может изменить то, как узлы реагируют на Wi-Fi, и, возможно, это снова будет сопоставимо с ядром 2.4.2.
Не уверен, какие исправления в ядре 2.5.0 включены, которые могут решить некоторые другие проблемы, с которыми мы сталкиваемся.

@ chunter1 Об
Похоже, что тот, который перезагружался, отправлял намного больше сообщений контроллеру, поэтому, с точки зрения статистики, у него больше шансов попытаться отправить что-то, что где-то застряло в процессе.

@ clumsy-stefan Можете ли вы протестировать текущий код на Github? (или последняя сборка)

Я внес некоторые изменения в то, как выполнять сетевую активность.

Вы имеете в виду это?

ESP_Easy_mega-20190227_test_core_260_sdk3_alpha_ESP8266_4M.bin

Практически любая сборка прошлой ночи.
Я также добавил "нормальную" версию для ядра 2.6.0 с использованием SDK2.
Core 2.6.0 SDK2 теперь работает на нескольких узлах, и только на одном из них был сторожевой таймер HW, который имеет исключительно мало ресурсов (работает много подключаемых модулей высокой памяти), а также тот, у которого, вероятно, изношена флэш-память (должна выбросьте его, так как у него было тысячи обновлений прошивки)

@ TD-er Я скомпилировал и установил из git около 6 часов назад на 2 тестовых узлах ... но поскольку у меня все еще очень ограниченный доступ в Интернет, я, вероятно, могу сообщить об этом только через 24 часа, так что ...

Я тестировал последнюю прошивку с "Force B / G mode" с роутером Mikrotik, и пока что она работает стабильно. Отчитаюсь.

@ TD-er Один вопрос: каково правило возврата к N-режиму, когда установлен "Force B / G mode"?

@ giig1967g
Если ему не удавалось подключиться к AP более 10 раз с использованием _B / G only_, он вернется в режим BGN по умолчанию.

Таким образом, остается возможность подключения в режиме N, если точка доступа какое-то время была отключена.
Если это кажется реальной проблемой, я могу попытаться настроить его так, чтобы он делал это только каждую 10-ю попытку, но тогда я должен убедиться, что он также будет пытаться это сделать, когда будет использоваться резервный ssid.

Привет @ TD-er
Я думаю, что запасной вариант - плохая идея.
Взгляните на этот сценарий: мое устройство принудительно переведено в режим B / G, успешно работающее с моим Mikrotik.
По какой-то причине мой Mikrotik отключается (обновление, перезагрузка и т. Д.).
Каждый раз, когда микротик снова включается, ESP подключается в N-режиме, и я теряю стабильность устройства.

Другими словами, если я установил режим Force B / G и соединение не удалось, тогда он должен стать AP (192.168.4.1), но не должен переходить в N-режим. Возможность отката создает ложные ожидания для пользователя.

Не поймите меня неправильно, резервный вариант был хорош для проверки действительности изменения, но теперь, когда он доказал, что решает проблему (по крайней мере, до сих пор), резервный вариант следует удалить.

Я согласен с комментарием @ chunter1 : https://github.com/letscontrolit/ESPEasy/issues/1987#issuecomment -462295204

Что вы тогда думаете о следующем сценарии?
Как только станет возможным подключиться к данной AP, используя только B / G, будет установлен дополнительный флаг, чтобы больше не было отката.
Если некоторые из этих настроек (только B / G или другие настройки AP) изменяются, откат будет включен снова, пока не будет успешно подключиться к данной AP.

Редактировать:
Под резервным я подразумеваю эти дополнительные настройки, а не резервный SSID.

Другими словами, откат остается активным только до первого успешного подключения к AP, после чего он удаляется. В этом случае было бы полезно увидеть на syspage режим Wi-Fi.
Это возможное решение, даже если я по-прежнему предпочитаю избегать отката к N, если я установлю Force B / G.
Я понимаю, что пользователь может ошибиться, но тогда пользователь может ввести неверный SSID и не получить доступ к устройству в любом случае ...

Еще один вопрос: в каком сценарии в текущей реализации устройство станет точкой доступа?
Потому что мне кажется, что устройство попробует B / G 10 раз, а затем попробует N, но откажется ли он в конечном итоге и станет AP?

Нет, режим AP остается активным при тестировании подключения к данным AP.
Возможно, нам также следует добавить дополнительную проверку на время безотказной работы и разрешить запуск режима AP только в первые 10 минут загрузки узла.
Просто для дополнительной безопасности, а также для исключения возможности того, что режим AP может повлиять на то, что ESP не сможет достичь данных сетей Wi-Fi.

И мы должны сосредоточиться на «легкой» части проекта.
Это означает правильные настройки по умолчанию и отсутствие огромного количества настроек, но дает возможность эксперту сделать все это.
Это также означает, что для менее опытного пользователя должен быть правильный запасной вариант.
Специально для настроек только B / G. Думаю, 90+ процентов людей, начинающих с ESPeasy, не знают о различиях между 802.11B / G / N, поэтому, если у них возникают проблемы, которые можно очень хорошо решить с помощью запасного варианта, это может заставить их искать другие проекты. .
Я также понимаю, почему этот запасной вариант не должен давать ложного ощущения «стабильности», поэтому я действительно понимаю, почему в текущей реализации есть возможности для улучшения. Но если «первая попытка подключения успешна => отключить резервное копирование» выполняется автоматически, то она также идеально подходит для более опытного пользователя. (который тоже делает глупые ошибки, как знаю по опыту;))

Я согласен, что следует более четко указать, какие настройки подключения активно используются.

понял.
Итак, плюсы:
Блок Сапоги.
Флаг N-fallback установлен в значение true.
Если установлен FORCE B / G, он пытается 10 раз подключиться к точке доступа Wi-Fi в B / G.
Если он может подключиться, он устанавливает для N-fallback flack значение false.
Если он не может подключиться, он пытается в N-режиме.

Также рассмотрите этот сценарий с установленным Force B / G: сбой питания.
ESP и Wi-Fi роутер выключены.
Затем питание возвращается, и ESP включается быстрее, чем маршрутизатор Wi-Fi.
В этом случае может случиться так, что после 10 раз точка доступа Wi-Fi все еще не слушает.
Таким образом, устройство попробует N-режим и в конечном итоге добьется успеха.
(Опытный) пользователь не будет знать, что соединение было в N-режиме и думает, что оно находится в режиме B / G с недостаточной стабильностью.

Я не хочу настаивать, но на самом деле проблемы с HW и замораживанием происходят уже год. Теперь, когда вы с помощью сообщества нашли одно рабочее решение, я настоятельно рекомендую убедиться, что оно по-прежнему применяется. Риск для неопытного пользователя установить "Force B / G mode" меньше, чем у него, установив неправильный SSID с теми же результатами: нет доступа к точке доступа.

ПРЕДЛОЖЕНИЕ:
Чтобы убедиться, что менее опытный пользователь не ошибется, почему бы вам не добавить кнопку в «Тестовый режим B / G». В случае успеха он включает «FORCE B / G mode», в противном случае он остается отключенным.

В этом случае менее опытные пользователи будут знать, что они делают, а более опытные будут уверены, что, когда установлен режим ForceB / G, он не сможет вернуться к N.

Что вы думаете?

Вы могли

Не только, если он загрузится, но и вариант отката будет отключен в настройках и сохранен.

Хорошо. Тогда даже более уместна ручная проверка вместо автоматической. Вам не кажется?

Да, сначала я добавлю простую галочку, чтобы отключить переопределения.
Но потом надо сделать это более динамично, чтобы и нам, «знатокам», было меньше ошибок :)

Хорошо

Версия 2019_02_16 теперь работала 9 дней без перезагрузки (принудительно B / G). Вчера снова начал перезагружаться. Сторожевой таймер оборудования дважды запускал это действие.
Через некоторое время объект больше не был доступен. Переключение WLAN роутера не помогло (пробовал 3 раза, до 30 минут). Не помог и перезапуск ESP переключением силового предохранителя.
Мне пришлось снова выключить wlan, а затем подключиться к ESP через 192.168.4.1 напрямую, чтобы получить к нему доступ

Я понятия не имею, что случилось

@kischde Какую
Прошлой ночью я сам испытал нечто подобное, экспериментируя с установкой новой точки доступа.
Я пытался установить MikroTik AP, и все работало нормально, пока ESP не потребовалось повторно подключиться.
Через веб-интерфейс MikroTik я мог видеть, что узел был подключен к WiFi, но не получил IP-адрес.
Даже когда я пытался подключить его к точке доступа своего телефона, я мог перезагрузить ESP, но он повторил это поведение.
Только когда я установил основную конфигурацию точки доступа на другую точку доступа, она начала подключаться как следует.

Обратите внимание, что для этого узел не был перезагружен.

Одна вещь, которая установлена ​​«неверно» на этой точке доступа, по сравнению с другим MikroTik, который у меня есть, - это то, что для нее установлено значение «Расстояние» «в помещении».
Я проведу больше тестов, чтобы увидеть, в чем разница, но, как обсуждалось ранее, похоже, что это некоторая настройка тайм-аута для ответа на пакет.
И я могу представить, что ESP действительно требуется некоторое время, чтобы ответить на запросы DHCP, которое может быть слишком коротким для этого параметра.

Я использую Swisscom AP (точка доступа швейцарского поставщика услуг связи), но у меня были все те же проблемы, написанные здесь в разных местах, как у ребят с MikroTik. Так что, возможно, он имеет тот же набор микросхем, но я не могу сильно изменить настройки, например, эти расширенные настройки.
Перед повторным включением я также пытался подключиться к своему мобильному телефону, как и вы, с тем же поведением, что и вы.
Я использую фиксированный IP, без DHCP
Перешел сейчас на актуальный 2019_03_05, посмотрю, что будет ...

Вы недавно меняли настройки WiFi?
Например, точка доступа с MAC-адресом AA: AA: AA: AA: AA на позиции 1 SSID другой AP с MAC-адресом BB: BB: BB: BB: BB: BB
У меня такое чувство, что в ESP остались некоторые настройки, где мы их не храним.

Я также постараюсь увидеть в документации по NonOS, как их можно эффективно очистить, когда мы изменим настройки Wi-Fi.
Также в моих тестах было очень полезно использовать более двух SSID.
Я также попытаюсь добавить для этого больше поля или, возможно, даже разрешить хранить некоторый зашифрованный файл в SPIFFS, чтобы хранить почти неограниченное количество точек доступа WiFi.

Вы недавно меняли настройки WiFi?

Нет, так как у меня только одна точка доступа, это было не IMO

ХОРОШО. Хорошо знать.
Поскольку я еще не знаю, что вызывает это, я пытаюсь устранить как можно больше неизвестных.
Итак, единственное, что вам нужно было сделать, чтобы он снова заработал, - это снова добавить настройку Wi-Fi.

Нет даже меньше
Я заставил подключиться напрямую к esp через 192.168.4.1 (отключил AP)
Затем я проверил все, но не обнаружил никаких аномалий ... Поэтому я попробовал и перезапустил свою AP, затем сбросил ESP, и он снова запустился. Так что IMO мне просто пришлось заставить сделать "нормальное / другое" соединение WLAN.
Кстати, я также видел, что он подключен к AP, но также не назначен IP-адрес, однако он статический

Хм, немного поигрался с 5 узлами, подключенными к MikroTik, с которым я играю.

Как только я устанавливаю «Hw. Fragmentation Threshold» (просто «разверните» опцию), узлы ESP больше не могут получать какие-либо IP-адреса.
Значение по умолчанию для этого параметра - 256. Если я установил его на 1600 (соответствует полному MTU), все узлы получат IP-адрес и продолжат работу.

Это отображается в пользовательском интерфейсе MikroTik, когда узлы могут обмениваться данными:

И это когда они не могут отправлять / получать данные (но подключены к уровню Wi-Fi)

@ TD-er, вы видели, что в новом ядре esp8266 есть опция под названием LWIP_FEATURES которая, я думаю, активирует повторную сборку IP ... Вероятно, это не определено в вашей сборке?

см. здесь: https://github.com/esp8266/Arduino/blob/192aaa42919dc65e5532ea4b60b002c4e19ce0ec/tools/sdk/lwip2/include/lwipopts.h#L748 -L754

также поддержка фрагментации IP устанавливается следующим образом:
https://github.com/esp8266/Arduino/blob/192aaa42919dc65e5532ea4b60b002c4e19ce0ec/tools/sdk/lwip2/include/lwipopts.h#L756 -L763

Хм, не знаю, какие настройки по умолчанию.
Являются ли числа, указанные в первой строке документации Doxygen, значениями по умолчанию?

Я не знаю ... Я просто знаю, что в Arduino IDE в файле определения plattforms вы можете выбрать, хотите ли вы, чтобы он был включен и определен или нет ..

Я всегда думал, что части LWIP были включены как предварительно скомпилированные библиотеки в основной дистрибутив.
Таким образом, довольно сложно убедиться, что LWIP перестроен с использованием правильных флагов.

да, но это зависит от того, на какой из них вы ссылаетесь (изboards.txt):

-llwip2-1460-feat
-llwip2-536-feat
-llwip2-536
-llwip2-1460
-llwip2

Итак, они используют эти флаги:

https://github.com/esp8266/Arduino/blob/192aaa42919dc65e5532ea4b60b002c4e19ce0ec/boards.txt#L357 -L387

| Этикетка | build.lwip_lib | build.lwip_flags |
| --- | --- | --- |
| v2 Нижняя память | -llwip2-536-feat | -DLWIP_OPEN_SRC -DTCP_MSS = 536 -DLWIP_FEATURES = 1 -DLWIP_IPV6 = 0 |
| v2 Более высокая пропускная способность | -llwip2-1460-feat | -DLWIP_OPEN_SRC -DTCP_MSS = 1460 -DLWIP_FEATURES = 1 -DLWIP_IPV6 = 0 |
| v2 Нижняя память (без функций) | -llwip2-536 | -DLWIP_OPEN_SRC -DTCP_MSS = 536 -DLWIP_FEATURES = 0 -DLWIP_IPV6 = 0 |
| v2 Более высокая пропускная способность (без функций) | -llwip2-1460 | -DLWIP_OPEN_SRC -DTCP_MSS = 1460 -DLWIP_FEATURES = 0 -DLWIP_IPV6 = 0 |
| v2 IPv6 Нижняя память | -llwip6-536-feat | -DLWIP_OPEN_SRC -DTCP_MSS = 536 -DLWIP_FEATURES = 1 -DLWIP_IPV6 = 1 |
| v2 IPv6 Более высокая пропускная способность | -llwip6-1460-feat | -DLWIP_OPEN_SRC -DTCP_MSS = 1460 -DLWIP_FEATURES = 1 -DLWIP_IPV6 = 1 |
| v1.4 Более высокая пропускная способность | -llwip_gcc | -DLWIP_OPEN_SRC |
| v1.4 Скомпилировать из исходников | -llwip_src | -DLWIP_OPEN_SRC |

Таким образом, все версии v2 имеют LWIP_FEATURES=1 кроме помеченных как "без функций"

да, но если вы посмотрите на операторы -l , вам нужно будет использовать библиотеки с -feat в конце (в отличие от ярлыка, немного противоречиво интуитивно) ...