Espeasy: [BUG] [WiFi稳定性]当第2层断开连接时，ESP异常3/29

听起来我有同样的问题。 有时我的esp失去了wifi连接，并从wifi中“丢失”了好几个小时。 我虽然需要看门狗，但他们必须重新启动并重新连接到wifi，但他们没有。 冷启动解决了这个问题。

@wolverinevn描述的最后一件事也是我在这里看到的。

正如我们在＃1957中讨论的那样，我可以肯定很多此类奇怪的WiFi /网络问题都来自第2层不稳定性...在将AP更改为某些增加的时间之前，我已经看到各种奇怪的行为...

正如我们在＃1957中讨论的那样，我可以肯定很多此类奇怪的WiFi /网络问题都来自第2层不稳定性...在将AP更改为某些增加的时间之前，我已经看到各种奇怪的行为...

希望您能找到解决方案。 我的一个Nodemcu挂起并从路由器中消失了5个小时，直到现在没有任何原因。 我希望它可以从看门狗中恢复过来，但是什么都不会发生。 我现在必须手动重新启动它。 很生气！

@wolverinevn，当您再次有权访问该节点时，转到tools => advanced并将“连接失败阈值”设置

另一个解决方法是，如果您可以调整访问点中的某些参数，则实际上取决于您可以调整的AP类型。

@ clumsy-stefan我们也应该在ESPeasy中将默认值设置为此级别吗？

也许我们还应该在sysinfo页面中显示此值，并将其用于规则？

如果它不是太低，则@ TD-er默认将它设置为某个级别可能不是一件坏事（连接失败总是会发生）。

在调试问题时，我考虑了如何完成此操作，当前每个不成功的连接都会增加计数器，而成功的连接会减少计数器。 我考虑过，一旦成功建立连接，将它重置为0是否更合乎逻辑，但是我想这是一个意识形态问题，什么才更有意义。

这个数字的问题是，如果您有10个任务，每个任务的重试计数为10，重发延迟为100ms，则在出现真正的通讯问题时，重启会很快发生（约10秒内重试100次）。 。

现在，例如，如果您始终有5次通讯失败和1次成功失败，那么您将不断增加连接失败次数。 如果一直发生这种情况，即使可以传递所有数据，您也迟早会重新引导节点。

我看到的主要问题是，节点以某种方式未意识到第2层上的连接实际上已消失，并继续发送数据（我猜）。 除了我今晚意识到的这些以外，如果没有wifi连接，syslog（以及NTP等其他通信）会怎样？ 这也停止了吗？ 这可以解释为什么第二层消失后，我的节点突然跳到100％cpu的原因。 可能没有更多的任务数据被发送，但是它试图摆脱UDP syslog数据包，并且不能...只是一个猜测...

抱歉，很长的文字有两个简单的问题……总之：
默认级别：是，我默认将其设置为最大（100）左右。如果一切正常，则对设备没有危害，再次可以访问...
sysinfo页面和规则：我不会，为什么要动态更改它？ 这是紧急值...

@ clumsy-stefan我已经将其设置为50。让我们等待。 ;）

@wolverinevn嗯...根据任务间隔和重试的次数（5-15分钟），应该很快发生50次。如果这没有帮助，我认为该节点实际上并未冻结，但是可以t重新连接到网络。 即使在WD重新启动后，我也有此问题。 您可以查看节点是否尝试进入AP模式吗？ 您看到节点的AP-WLAN吗？

sysinfo页面和规则：我不会，为什么要动态更改它？ 这是紧急值...

我的意思是要使用%conn_fail%类的系统变量在规则中进行检查，并将其显示在sysinfo页面上，在wifi重新连接次数旁边。
毕竟，这是性能统计值

我的意思是要使用％conn_fail％之类的系统变量在规则中进行检查，并将其显示在sysinfo页上的wifi重新连接次数旁边。 毕竟，这是性能统计值

啊，是的，同意，那是有道理的！ 这也与1993年的问题有关。 拥有一个可以定期向控制器发送多个系统/性能变量的插件（而不浪费有限的可用任务）真的很棒！

@wolverinevn嗯...根据任务间隔和重试的次数（5-15分钟），应该很快发生50次。如果这没有帮助，我认为该节点实际上并未冻结，但是可以t重新连接到网络。 即使在WD重新启动后，我也有此问题。 您可以查看节点是否尝试进入AP模式吗？ 您看到节点的AP-WLAN吗？

我有9个任务，其中3个是Dummy和MQTT_import。 我认为规则有点忙于计算和读取传感器，我试图通过每隔几分钟调用规则来限制mqtt_publish。 负载约为29％。
我记得，上次冻结是在今天早上，我找不到Espeasy的AP（如果您表示AP_WLAN在AP模式下运行）。
我的设置（网络，ESP的位置）与3月份发布的运行2.3或2.4的另一个Nodemcu一起使用时效果很好。

_Uptime是7小时20分钟，RSSI是-71dbm，我周围有一些wifi。
上次断开连接的原因： （200）信标超时
号码重新连接： 35_

@wolverinevn这个问题的问题是，它完全随机发生。 我正在运行约30个节点，其中一些面临一些问题，其中一些没有重启，有些无法进入AP模式...

看来，这实际上是节点繁忙程度，空气繁忙程度（例如wifi设备数量）以及AP如何严格处理某些条件（missnig第2层码头等）的组合...

因此，我猜直到我们在应用程序（ESPEasy）中找到可靠地检测到这种情况并对其采取行动的方法之前，还没有“真正的”解决方案...。

@wolverinevn PS：您不是偶然使用mikrotik AP的吗？

@wolverinevn关于重新连接的次数（在您的编辑中）
在大约8小时内进行35次重新连接很多。
我的节点在这里运行了几天，只有很少的重新连接。
最稳定的设备现在可以运行20天11小时46分钟，而只有1个重新连接。

已连接| 19d22h33m
-| -
上次断开连接的原因| （202）验证失败
号码重新连接| 1个

@wolverinevn PS：您不是偶然使用mikrotik AP的吗？

否。我正在使用运行Padavan固件（华硕类型）的路由器。

@ TD-er我知道。 我正在检查原因，可能是附近的降压模块发出的噪音。 2小时后，另一个连接有0个重新连接。

否。我正在使用运行Padavan固件（华硕类型）的路由器。

不幸的是，我根本不了解这个固件。是否有机会调整第2层参数？ 诸如帧确认超时之类的东西？ 某种“距离”设置？

@ clumsy-stefan不幸的是，我没有看到这样的东西。

@ clumpsy-stefan昨晚已将设备重启两次，并设置了50个故障阈值。 好消息不再冻结了。 今天，我将通过对硬件设置进行一些小的更改来尝试改善wifi连接。

同一房间中的3个Wemos设备连接到同一AP。
最近16个小时左右重新连接，
使用规则：在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（以秒为单位）的“密钥更新间隔”。
这样应该可以吗？

重新输入密钥会超时

那只能解释每小时一次的重新连接恕我直言。
多亏了强大的规则功能_WiFi＃Connected_，我们才能看到这一点。
不知道旧版本如何执行此操作。
一个隐藏的问题已经很久了？

设置我的组密钥从5分钟后重新设置。 到1小时后，设备运行更加稳定。 我假设有40个客户端连接到一个AP，每5分钟执行一次。 重设密钥只是让空气变得太忙了。.之后，我什至可以再次减少帧确认超时，并且单元再次变得更加敏感，而且在更改这些参数后，我的“连接超时”也更少了。

@ 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

未连接节点ESP时，RSSI值不可靠！ 当连接时，同一节点的值小于-70。...在深度睡眠的节点上，当发送值时，它们甚至显示“未连接”默认值+31！
重新启动后，它运行就没有问题...（不移动它...），如果您阅读以上内容，则是第2层问题，当您在AP上调整参数时，该问题可以重现...。

PS：您可以自己尝试！ jsut连接20到30个节点，并将组键timout降低到5分钟。 帧回复阈值大约为7 ...看看会发生什么！

我认为这是第二层问题的地方，您应该在esp8266内核上填充问题，或者在nonos sdk项目上可能更好
但是请不要在这里喊

它只会在ESPeasy上发生，而不会在我尝试过的其他类型的固件上发生。 我假设节点在某个时间点变得太忙，并且没有为核心留出足够的时间来进行密钥更新（所有内容都被解释了多次），所以请随时阅读调试和解释...
但我同意，您实际上不需要回答...
PS： @ uzi18您曾经有30个节点同时成功运行吗？

@ TD-ER：在ESPEasyWifi.ino行650 - 669个switch语句的默认匹配中断了开关，因此tryConnectWiFi()返回true即使WiFi.status()是不一定是WL_CONNECTED而可以是任何其他状态（仅检查2个错误的返回状态。）。

仅当WiFi.status()实际上返回WL_CONNECTED解决了我所面临的第2层断开/异常问题中的至少一个问题时，才更改此值并返回true ！

你怎么看？
我是否缺少某些东西？为什么WiFi.status()不是WiFi.status() CONNECTED时，为什么tryConnectWiFi()返回？

@ clumsy-stefan很高兴看到您仍在研究WiFi代码。

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

此功能的最初想法是启动WiFi连接序列。
从那以后的所有变化中，其功能可能都发生了一些变化。
但是您可能会在这里遇到一些麻烦。
我认为只有在状态返回时，才可以对return true （在该函数的末尾）进行适当的更改。

您能描述一下您面临的另一个第二层问题吗？

无法确切地说出另一个异常发生的时间，但如果状态为WL_CONNECTED时此函数仅返回true ，则至少存在差异，我在更改前后附加调试。 。

之前

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此状态是因为我们无法中继Arduino wifi状态，这就是@ TD-er引入ESPEasy状态的原因，但是好吧，我们可以尝试仔细检查代码中的每个状态是否都经过正确检查。

wifi状态可能已在核心2.5.0中修复，因此我们自己的状态可能已过时。
那样很好，因为它会使WiFi代码变得相当复杂，从而容易出错。

编辑：
我正在查看您给出的此错误：
Fatal exception 9(LoadStoreAlignmentCause):
核心2.5.0中最新的修复程序之一是关于IPAddress的构造函数，当给定字节序列的对齐方式不是32位对齐方式时，它应该解决问题。
也许这是类似的东西？

这是我的猜测之一，ESPEasy状态并不总是与Arduino状态同步。 特别是第2层上的临时断开连接（例如，WiFi中继）可能没有真正处理/实现。

另一件事可能是相反的，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()回调...

或多或少总是相同的情况。 在四次握手失败（重新启动）之后，它再也无法恢复了……不确定如何强制执行此操作。

至少在processConnect()和processDisconnect添加一些delay(100) ，从而给核心时间更新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之前的某种功能吗？ 似乎它从未到达该函数的最后两行...

是的，这是基于事件的wifi之前的某种遗留物。
我认为我们确实应该考虑再次查看该WiFi代码，因为它的结构不尽如人意。

好的...我仍在调试由于4way握手超时而导致的确切情况以及为什么节点将不会再次重新连接....但是我认为我仍然在暗中摸索，但在此处发现了一些小错误，那里可能加起来....

似乎还有另一个小地址位于WifiCheck() ...中，仅当IP不再有效时（例如，所有八位位都为0），才进行第2层连通性检查。 这可能导致第2层断开（或重新）连接/握手等情况，但是IP仍然有效，因为IP尚未过期（DHCP）。 这可能就是为什么“ DCHP更新可能失败”仅在很长一段时间之后才发生的原因，而实际上租约已经消失了……但是我仍在对此进行核实……

还有wifiCheck() ， WiFiConnected()和connectionCheckHandler()都进行某种连接检查，并在一定条件下互相呼叫以及resetWiFi() 。尤其是connectionCheckHandler()似乎仅在mqtt_reconnect_count > 10时才被调用。 那么在非MQTT环境中会发生什么呢？

PS：我只是在这里记录我的发现，以寻找潜在的WiFi麻烦...因此，我很高兴对此有任何想法，但并没有必要的期望...

某处必须有某种神秘的种族条件。 当AP启动重新认证或重新启动时，有时节点/核心没有获得足够的CPU时间来完成握手，或者在这样做时被打断，尤其是在信号低的节点上（因此握手需要更长的时间）。 。 （见下文）。

这些重做/重新认证似乎由内核生成了一个断开事件，即使内核将进行自动重新协商或重新协商（据我所知）。 但是随后，由于手动重新连接被触发，此握手过程似乎被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

因此，也许我们应该只使用wifi事件来监视进程，而不是自己采取行动？
更改此设置将使2.3.0甚至2.4.0版本无法使用。

不，我不会那样做。。。在我的分支机构中，我已经做了一些（不是那么侵入性的）更改，这些更改似乎使这些案件的发生频率降低了……

刚刚发现了另一个小问题：在tryConnectWiFi() WiFi.begin()调用开始返回WL_DISCONNECTED之后，在tryConnectWiFi() ， WiFi.status() $$$支票把结尾拧了。 根据文档，这表示“如果未在站模式下组态模块”。 试图找出原因，或者实际上是否有助于在调用WiFi.begin()之前将esp明确地置于AP模式

因此，我仍然希望找到导致这些停顿的“真正”根本问题……如果是这样（手指交叉），我建议我对所有更改进行公关，以供您（和其他人）审阅...。

请知道，我也看到过很多情况，其中WiFi.status()的状态不正确。
因此，也许核心库现在已修复，并且很可能在使WiFi行为稳定的所有尝试中也弄乱了地方。
调试非常困难，因为我自己无法重现这些问题，而不得不对其他用户的报告采取行动。
最近，我有一个在WiFi方面表现也不佳的模块，所以这是我最喜欢的WiFi测试模块。 但这也可能表明，当某些零件接近规格时，问题将变得更加严重。 例如电源，缺少去耦电容器，（太）薄的PCB走线，更少的屏蔽等。

当然，不是我要排除硬件问题。 但是我有约40个节点在运行，具有各种不同的电源，不同的电路板，品牌等...并且在某个时间点上，大多数节点都面临连接问题...尤其是那些wifi覆盖较弱或存在很多问题的节点。 GPIO正在使用中..

而且我目前确实有一些时间来进行一些调试，但我仍然觉得它非常有趣和具有挑战性；）到现在，我什至开始了解连接，检查，断开连接等整个过程的工作原理；）

因此，如果您满意，我将继续深入研究这些连接问题....尽管您是老板....

请继续挖掘:)
我真的想摆脱几乎无法重现的所有断开连接问题。
现在它们已经花费了太长时间，如果修复它们，那将真的很棒。

我的正常运行时间约为4-24小时，平均停机时间为2-10小时。
在停机期间，节点继续工作，但是没有wifi连接。

接入点（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简易| 信息|
----- | ----- |
内部版本：⋄| 20103-Mega |
库：⋄| ESP82xx Core 2_4_2，NONOS SDK 2.2.1（cfd48f3），LWIP：2.0.3 PUYA support |
GIT版本：⋄| mega-20190110 |
插件：⋄| 7 [Normal] [Sonoff POW R1 / R2] |
建立时间：⋄| 2019年1月10日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 ：

Wifi频道是固定的。

任何通道都可能受到其他通道的干扰，无法对其进行控制。 地狱，甚至可能来自同一频道的干扰。

顺便说一句，关于我所面临的问题-wifi状态指示灯（反向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]]
Gesendet：弗赖塔格，11. Januar 2019 21:47
An：letscontrolit / ESPEasy
抄送：已订阅
Betreff：回复：[letscontrolit / ESPEasy] [BUG] [WiFi稳定性]当第2层断开连接时，ESP异常3/29（＃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/AomgSxPjVKWrp0MSQTtbESKxFqaPVt90ks5vCPgxgaJJPZM4YD静音。 https://github.com/notifications/beacon/AomgS_fhHQnmg1AdpX11mVL9yNra8S_kks5vCPgxgaJpZM4YDivP.gif

Mikrotik的东西提供了强大的功能，但即使是wifi的默认设置也不正确。

• 确保您没有安全性设置tkip并仅启用AES CCM加密
• 输入密钥组更新（例如30分钟或1小时）
• 在通道中具有20Mhz的通道宽度，在我看来，B波段是D / G
• 扩展频道已禁用
• 仅禁用PMKID（如果对安全性存有疑问，建议禁用）似乎会使Esp的工作人员感到不快
• 将您的国家/地区添加到wifi设置中（或查看您拥有的AP的最大功率是多少，并将发射功率降低3）。 这通常会提高wifi性能（我知道反直观）

我通常不会断开连接（除非当我有此PMKID东西时）

无论如何，无论如何发布AP设置都是有见地的：-)

这些都是不错的提示。 我对网络非常精通，并且在mikrotik方面甚至更有经验，我已经按照您的要求配置了所有功能，除了组密钥。

组密钥更新仅与组密钥有关，而与问题所在的单播密钥无关，但是出于实验目的，我将该设置降级了。

@ 0ki Cool不认识您，RouterOS的专家在哪里！

我已经得出结论，这显然是ESPEasy软件中的错误。 您可以在右侧看到与RouterOS相匹配的有问题的行为，在左侧断开了行为异常的客户端的连接。 如您所见，无线电频谱很清晰。

不幸的是，我现在没有时间深入研究ESPEasy代码库，但是我相信比较好的和不好的沟通将是有用的。
图例：__red-接入点| 蓝色-espeasy | 绿色-我的物联网网络上的另一台设备__

我认为ESP_easy出于某种原因决定在收到assoc响应（左侧的帧380）后决定切换到AP模式，而不继续进行四次握手。 还要注意espeasy macaddress的更改-第一个八位位组从80更改为82。

@ 0ki

我已经得出结论，这显然是ESPEasy软件中的错误。

我也是，但是我不知道错误应该在哪里。
似乎ESPeasy的有关断开状态的内部状态与真实状态不同步。
我很可能在编写该代码时犯了一些错误，或者这是核心库中的错误。

您所说的“那个代码”具体指的是哪个文件？ 如果您指向一个或两个文件，我可以看一下。

否则-因为现在您可以看到发生的确切时刻，所以希望您可以仔细研究一下。

由于我正在深入研究这个问题（大约2个月了），因此我不确定是否是ESPEasy代码本身。 更多ESPEasy与WiFi核心/库之间的交互...我的调试/日志显示，“断开”总是在组密钥交换/重新启动后发生。 但是回调仅在密钥更新超时后以及身份验证失败之后才被调用...因此，目前我的猜测是，ESPEasy没有为核心留出足够的cpu时间来实际执行重新启动...到目前为止，我没有找不到一种方法来找出该节点何时处于此rekeeying节点中或处于reauth模式，因此无法添加足够的delay()调用，因此rekeeying reauth成功。

为了及时查明问题-可以正常使用：

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上的隐藏AP。

@ clumsy-stefan，我完全支持捕获导致其首先断开连接的问题，但是老实说，WiFi assoc可能掉落可能有多种原因，当然，组密钥交换不应该是其中之一他们。

更为紧迫的问题是-断开连接后为什么不能重新连接。 这不会是时间问题，因为我给espeasy多达5000ms的时间来回复4way HS的消息2。

我认为问题在于，只有在密钥交换失败后才能断开连接……因此，从现在开始交换真正开始时，您再也不需要了，这就是您需要给核心更多时间的地方……

在日志中，您可以看到ESPEasy认为相当长的时间它仍然保持连接状态，即使它不是（即使对节点执行ping操作也失败），但是该节点仍然尝试发送数据（显然连接失败了）。

我完全同意的第二个问题是，即使断开连接，为什么也不能以全新的连接顺序重新连接...可能是模块或内核陷入了某种奇怪的状态？

编辑：PS：4way HS不会总是失败，（我每10分钟执行一次），所以这似乎是ESPEasy的状态/繁忙程度以及HS发生的时间的组合。

我能做的是，尝试完全断开WiFi（还关闭调制解调器），并在发生意外断开连接时开始完全重新连接。
不确定是否在此线程中，但是在其中一个问题中，有人回答了Shelly某人的一条推文，他说他们必须在断开连接后完全重新启动wifi堆栈。

@ TD-er也是我在最新版本中添加的内容。 在processDisconnect()我不确定是否添加了setWifiMode(WIFI_OFF); ，是否足够...当前它在某些测试节点上运行（大约1h）...

@ TD-er是个很不错的主意。 推送git版本，我会刷新内容！

我刚刚在5分钟前开始阅读一些代码库，所以这可能无关紧要，但是：同时，请确保在那时将wifi_connect_attempt设置为0。

嗯...在每个子例程调用之后，在backgroundtasks()添加了一些delay(0) ，似乎进一步稳定了第一个问题（4way-HS）。 不知道这是否是巧合...
@ TD-er可能是backgroundtasks()在某个时间点阻止执行吗？

一般而言：在时序器显示较长处理时间的各种不同地方添加delay(0)似乎可以大大改善4way-HS的处理。 从症状上讲，我现在有更多的SW / HW看门狗了（但是仍然有一些问题）...从症状上讲，所以我说这与核心/ wifi部分确实没有足够的周期来实际完成（相当快）像rekeeying这样的事情有关然后AP厌倦了等待答案...

我还看到的是，有时client.connect()或sendData()会花费很多时间（最多2秒）。 在一些文档中，我发现如果花费的时间超过50毫秒，则应在两者之间调用delay(0) ....，但是由于库执行这些调用，因此无法拆分这些调用...

内核中还有另一个回调onStationModeAuthModeChanged 。 也许值得一看，因为这个可能是在实际断开连接之前触发的。 但这很少有记载...有人有经验吗？

编辑：这似乎是一个巧合/竞赛条件，当AP请求重新输入密钥时，beeing还完成了其他一些事情....但同样只是观察...

我不知道AP发送的这些请求多久发送一次。
通常，每102.4毫秒发送一次来自AP的信标信号。 如果某些任务花费的资源更多，则ESP会丢失此类信标帧之一。 所以我不确定这有多严重。
我确实知道有时会错过ARP请求，这导致了一个问题，即交换机不再知道如何将数据包路由到该MAC地址，从而使ESP无法访问，而它仍然可以自行发送数据。

丢失信标帧没什么。 它甚至不需要信标帧，因为无论如何它都应该积极地探测我的隐藏网络。

我不是WiFi专家。
据我了解，信标间隔是ESP尝试收听WiFi的唯一（有一定保证）的时刻，在此之间，ESP会尝试尽可能多地睡眠。

而且据我所知，“隐藏”网络和“非隐藏”网络之间的唯一区别是SSID没有被广播。 因此，实际上它仅基于BSSID（AP的MAC地址）进行连接。
这也是ESP在连接（非隐藏）WiFi网络时所做的事情，唯一的不同是，ESP之前将执行扫描并尝试查找具有与给定SSID匹配的SSID的BSSID。
执行自动重新连接时，它将首先尝试最后一个已知的BSSID +通道组合，而不执行扫描。 换句话说，它仅在建立连接时有所不同。

因此，据我所知，只要有网络连接，它也会监听信标帧。

我不是WiFi专家。
据我了解，信标间隔是ESP尝试收听WiFi的唯一（有一定保证）的时刻，在此之间，ESP会尝试尽可能多地睡眠。

据我了解，“隐藏”网络和“非隐藏”网络之间的唯一区别是……。

哦，这使我想起了一些可能很重要的东西。 我在隐藏的SSID中运行我的ESP
顺便说一句，仍然没有断开或重新启动我的节点（尝试5分钟的组密钥更新）

由于断电，我的一个节点在12月5日重新启动。

这是从那一个：

单位： 5
-| -
当地时间： 2019-01-15 23:27:32
正常运行时间： 41天12小时46分钟
负载： 15.80％（LC = 9135）
免费内存：| 12160（5360-sendContentBlocking）
免费堆栈： 3552（1520-SensorSendTask）
引导：| 冷启动（0）
重置原因： 外部系统
网络❔
Wifi： 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
已连接： 20h04m
上次断开连接的原因： （202）验证失败
号码重新连接： 61
固件
建立：⋄| 20102-Mega
图书馆：⋄| ESP82xx Core 2_4_2，NONOS SDK 2.2.1（cfd48f3），LWIP：2.0.3 PUYA support
GIT版本：⋄| 巨型-20181109
插件：⋄| 46 [普通]
建立Md5： 47f19d99d0c3f083314b45668b1f5c
Md5检查：| 通过了。
建立时间： 2018年11月9日03:23:22
二进制文件名：⋄| ESP_Easy_mega-20181109_normal_ESP8266_4096.bin

如您所见，平均每天有多个断开连接。 它已连接到AVM Fritzbox 1750E

我认为信标帧并不是那么关键...我仍然不清楚为什么在断开连接后，正常的WiFi.begin()序列始终会因'(2) Auth expire'失败。

唯一的指示是，此时的CPU负载始终显示为100％，并暗示核心只是没有足够的时间进行握手...

我的猜测是核心库（LWIP或Arduino或ESP）有问题，我们应该重置wifi。
因此，请关闭wifi并重新开始。 也许还要在这​​些步骤之间等待，以确保清空缓冲区或至少清空缓冲区并主动取消未完成的请求。

@ TD-er您可以推送此更改，以便我知道它是否有效吗？

最近2个帖子中讨论的更改？
它尚未实现，但今天晚上我可以尝试对其进行编码并进行测试构建。

是的，重置wifi。

@ TD-er写道：

因此，请关闭wifi并重新开始。 也许还要在这​​些步骤之间等待，以确保清空缓冲区或至少清空缓冲区并主动取消未完成的请求。

不确定是否刷新...因为我在client.stop()之前删除了所有client.flush()调用，这似乎也很少发生断开连接。 在阅读一些文档时，我看到刷新清除了所有（tcp）输入缓冲区，因此从理论上讲，回复可能会丢失...

仅添加我的2c，我就有一些Mikrotik AP，一些探子运行espurna，一些NodeMCU运行ESPEasy。 我必须为ESP设备添加一个额外的AP，因为在网络的高流量期间（如备份），我会丢失我的ESP设备。 我认为这与WiFi信号强度和流量有关。 添加了额外的AP后，我不记得再次遇到此问题。

但是我的NodeMCU和ESPEasy设备确实存在一些断开连接。 我将为设备设置一个netdata ping监视器，看看是否可以确定何时，如何以及为什么会发生这种情况，并查看是否提供一些信息。

另外请注意，我没有40多个设备（例如@ clumsy-stefan），只有大约5个用户及其移动设备，还有奇特的智能设备（例如电视），但可能是Mikrotik设备过载或WiFi RF网络饱和？

我希望我有办法查看射频噪声的数量。 我有一个应用程序（WiFi分析器）向我显示AP的数量以及它们如何传播WiFi通道。 我使用此工具为不同的WiFi AP设置了WiFi通道。

但是无法真正确定是否还有其他RF干扰。

关于超载Mikrotik设备的想法，我将MikroTik 951UI-2HND用于我的主路由器，并将MikroTik RB9412nD hAP lite用作我的ESP AP。

我想知道该信息是否有任何用处？

@LeeNX感谢您的提示。 我的节点分布在3个AP上，RF有所平衡（每个AP最多20个客户端），因此干扰尽可能小（当然不能有任何干扰……）。 因此，我不认为MT过载（我在一家提供专业活动的网络骨干连接和WLAN等的公司工作，所以我对基础设施进行了深入测试），但是我同意过载的时间可能是一个问题...但是，即使是这样，一个节点在断开连接后再也无法进行250次以上的重新连接，然后在重新启动后立即重新连接，我认为这不是通话时间的问题...除了我，在其他任何设备上都看不到...
所以我仍然认为这是内部wifi芯片的状态，wifi核心获得的cpu时间以及ESPEasy部分正在运行的其他任务之间的某种巧合或竞争条件...

@ clumsy-stefan我同意您的见解。 我只是想指出，使用带有40个以上节点的小型Mikrotik AP可能是Mikrotik CPU或RAM受限制的，但这似乎不是问题。

我想知道是否只使用基本的ESPEasy核心而不部署ESP32和NodeMCU设备，然后让它运行，以便我们可以测试ESP CPU，而没有其他插件的影响。 查看我可以部署的内容和netdata ping测试。

如果这为我们提供了有用的信息，我将进行报告。

多谢你们！！！

我的节点确实没有运行（IR RX / TX），并且运行了数周之久，没有任何问题。
运行时间超过40天的另一个节点正在运行Domoticz MQTT和BME280 + MH-Z19 CO2。
因此，它还可能取决于哪个插件正在运行以及运行的频率以及读取间隔是否始终与其他插件的读取间隔匹配。

我已经在调度程序中设置了一些具有初始偏移量的定期函数调用（10 / sec，1 / sec和30sec），以便它们在不同的循环调用中保持尽可能多的运行。

也许我还应该像Tasker一样添加一些中断计时器驱动的事件（或者简单地使用
唯一的是，它可能会中断其他GPIO传输，从而干扰传感器读数。

可能会解决4way-HS问题，但我想不是重新连接问题...那仍然是最奇怪的问题...我只是让我的测试节点再次失败了12个小时，试图重新连接到AP超过300次而没有成功。 （soft-）重新启动后，它立即重新连接（reboot + reconnect花费了大约5秒钟左右）...

我刚刚发现了这个问题，该问题与我们在这里看到的内容非常相关：
https://github.com/esp8266/Arduino/issues/5527

看起来很像，是的。。。但是关闭wifi似乎并没有改变它（尝试过），目前我正在尝试使用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在@ clumsy-stefan提到的问题中，还提到了AP的重新启动： https :

因此，似乎我们手头有几个问题。

@ clumsy-stefan
喔好吧。 而就我而言，只有Mikrotik ... :(
@ TD-er
也许您应该问他们正在使用哪个AP品牌/型号...

@ giig1967g我在这里也有一些节点无法访问，但是这些事件的间隔时间超过10天，因此很难确定它是否与这些问题之一有关。
现在，大约有一半的节点连接到Mikrotik，另一半连接到Fritzbox 1750E

@ giig1967g我也只有MT ...似乎在信号较弱的节点和使用GPIO的节点（特别是PCF）中更常见...

我希望我有办法查看射频噪声的数量。 我有一个应用程序（WiFi分析器）向我显示AP的数量以及它们如何传播WiFi通道。 我使用此工具为不同的WiFi AP设置了WiFi通道。

但是无法真正确定是否还有其他RF干扰。

您可以在mikrotik上进行/interface wireless registration-table print interval=1来查看snr。

不幸的是， WiFi.setOutputPower(0)还是没有帮助...在运行了将近6个小时（没有对wifi基础架构进行任何更改之后，突然又陷入了僵局（请参阅下面的串行输出），从此以后再也无法恢复，除非碰巧有SW或HW WDT启动...

这似乎仅在“组密钥更新超时”或“ 4向握手失败”之后发生。 如果我手动将节点从AP上踢开，它也会收到“验证过期”，但可以立即重新连接...

串行输出（否则负载将达到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来提高灵敏度。
我反对的目的是（是？）大多数AP在N，G和B之间切换时遇到问题。
您有混合客户吗？ （G和N）在同一AP上处于活动状态？

我在所有Mikrotik上使用不同的模式。 B / G / N / AC混合在一起，也包括虚拟AP在内都在2 / 5GHz频段...不同的客户端在同一AP上以不同的模式连接，没有问题（esp8266除外）。

好消息（至少对我而言）...我的节点在过去的12个小时内没有断开连接/重新引导/冻结！

强迫节点加入802.11g似乎可以与MikroTik AP一起正常工作。 至少这是一个简单的解决方法（只要您不需要802.11n的额外速度）。

如果有人要测试自己，只需在函数tryConnectWiFi()的ESPEasyWifi.ino （在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天的实验。
mega-20180224节点-零重启
mega-20190110节点-35次重启; 今天有9个。

我在代码中留下了相关行，但将其注释掉。 因此，您需要删除ESPEasyWiFi.ino中的//（约644行）并重新编译！

@oki抱歉，我只是看到我错误地读了您的问题...不包括此内容，因为在重新连接之前将电源设置为0时我看不出任何区别...所以我再次丢弃了该问题！

我已经进行了7天的实验。
mega-20180224节点-零重启
mega-20190110节点-35次重启; 今天有9个。

这实际上是在比较：

• 核心2.3.0，无基于事件的wifi
• 核心2.4.2和基于事件的wifi。

好消息（至少对我而言）...我的节点在过去的12个小时内没有断开连接/重新引导/冻结！

强迫节点加入802.11g似乎可以与MikroTik AP一起正常工作。 至少这是一个简单的解决方法（只要您不需要802.11n的额外速度）。

我以另一种方式进行了测试。
我仅将Mikrotik设置为N模式，并且...自12小时以来，所有ESP均在运行，而无需一次重新启动。

好的和有效的方法呢！ 不幸的是，我无法做到这一点，因为我处理了许多没有N功能的客户端...

只需禁用B模式并仅启用G / N。 如果没有B模式，您会更好。 除非您拥有10年前的旧电话或（通常）wifi条形码扫描仪，否则仅支持B模式和速率。

在B模式下增加的天线灵敏度在范围内也不会起任何重要作用。 B模式只会吃掉通话时间。 从字面上看，不使用B模式没有任何缺点，而使用G之上的N模式也没有任何缺点。 N模式的范围甚至比B和G更好。

@ jimmys01你是对的，B模式可能不再使用了……但是我不能只使用N模式……因此，如果节点保持稳定，那将取决于G / N模式的情况并能够在4way HS超时的情况下重新连接。

g / n对我来说不稳定。

这是否意味着esp8266每次在模式（B / G / N）之间切换时都会遇到麻烦？

这是否意味着esp8266每次在模式（B / G / N）之间切换时都会遇到麻烦？

非常可能。
我看到一些仅支持G模式的设备（不是ESP设备）存在很多问题。
如果将它们与N个设备混合使用，则它们似乎无法访问。
臭名昭著的是HomeWizard和一些WiFi摄像头。

有了这个新版本mega-20190121，ESP似乎更稳定，到目前为止，我还没有出现崩溃/局域网问题。
但是现在我无法关闭OLED（framedPlugin）。 当我发送OLEDFRAMEDCMD时，关闭它会在很短的时间内关闭显示器，然后再次打开。
我对旧版本（从2018年开始）进行了背对背测试，显示效果符合预期。

刚刚尝试过的mega-20190121和WiFi稳定性是一样的。 它在启动后约一个小时内崩溃。

@ TD-er，您认为什么时候可以发布讨论了更改的版本，以便我进行测试？

快速更新：由于将模式修复设置为802.11g，所以我不再冻结，重新启动等！ 即使AP在混合g / n模式下运行...所以我也投票支持使esp上可配置wifi模式的补丁！

希望很快也有补丁😉

我刚刚添加了一个仅选择B / G的提交。
它在ESP32上尚无法正常工作，因此我禁用了为ESP32选择它的选项。
我还添加了一个后备选项，可以在AP不允许仅B / G时再次连接。

@ TD-er我的意思是这个变化：

我的猜测是核心库（LWIP或Arduino或ESP）有问题，我们应该重置wifi。
因此，请关闭wifi并重新开始。 也许还要在这​​些步骤之间等待，以确保清空缓冲区或至少清空缓冲区并主动取消未完成的请求。

最近2个帖子中讨论的更改？
它尚未实现，但今天晚上我可以尝试对其进行编码并进行测试构建。

@oki我尝试了两种变体，将输出功率设置为0，并在出现问题时主动断开连接/重新连接。 这两个版本都无法帮助重置/重新连接到AP ...（在我的环境中）...上面的详细信息...
使它稳定的唯一方法是使用N模式。

我很清楚这一点。 希望尽快获得补丁，以便我可以继续进行调试。

@ 0ki我可以使用此最新提交为您创建一个testbuild。
还是您还想测试禁用WiFi的能力？

如果是这样，您想要/需要什么选择？ WiFi关闭/重新启动并重新启动所有服务？
最后一部分（重启服务）也是一件值得一看的事情，因为我不能完全确定使用套接字的所有服务都可以正确重启。
我猜想这可能还会导致一些问题，当重新创建WiFi连接时。

当检测到断开连接时，自动完全关闭（然后打开）wifi发射器。

我看到您已经添加了一些代码。 我可以拉哪个版本进行测试？

不确定，我将新建一个测试版本。
它将在+/- 30分钟内完成。

测试版本
它基于我今天早些时候与PR＃2235合并的内容，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可以帮助您重新启动它，因为它可能难以到达并且进入了一些重新连接循环。

即使使用此设置，它也可能仍显示硬件监视程序重新启动，因为我的许多节点已经显示。
在启用B / G模式的情况下，可能很难复制它们。

测试版本
它基于我今天早些时候与PR＃2235合并的内容，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 x 1线传感器和FHEM服务器）引起的。

您也可以尝试添加此补丁： https :
也许这也将有助于提高稳定性。
它包含在此测试版本中

您也可以尝试添加此补丁： 9a05eaf
也许这也将有助于提高稳定性。
它包含在此测试版本中

谢谢！
将其安装在两个完全不同的配置单元上，并将提供反馈。

在我的一个测试节点上运行过
https://github.com/letscontrolit/ESPEasy/commit/9a05eaf828a737ae416ab11c8df8c4a5b03ceaf不幸的是，仅花了大约2个小时才再次遇到组密钥超时问题，并且没有恢复或重新连接到AP。 启用“重新启动连接时丢失wifi”，并且不将其强制为B / G ..因此N似乎仍然是一个问题。
因此对我来说，B / G模式仍然是唯一稳定的工作选项。

我们可以看看完全放弃N支持吗？ 对于这样一个简单的设备，我们是否需要N提供的好处？

@ 0ki具有“新”选项，可强制使用@ TD-er内置的B / G模式，它基本上是在软件级别删除N，您无法从我假设的核心库中删除它...

将其移至主要设置时，我建议默认情况下此选项为开。

我们可以使其动态。
如果无法建立连接，请再次打开N选项。

有许多设置在AP中仅检查了N个设置。 因此，在这些环境中，如果要在ESPeasy上禁用N支持，则无法返回。

您也可以尝试添加此补丁： 9a05eaf
也许这也将有助于提高稳定性。
它包含在此测试版本中

谢谢！
将其安装在两个完全不同的配置单元上，并将提供反馈。

到目前为止，一个模块在2天后重新启动，另一个在5天后重新启动。
两者都显示“硬件看门狗”作为重置原因。
两个模块均设置为“强制WiFi B / G：是”和“在丢失的连接上重新启动WiFi：是”。
AP是仅设置为B / G的Mikrotik（正常运行时间49天）。
AP和模块之间的距离约 2 ... 3米

我想知道为什么我提出的使其动态化的建议（仅从B / G设置返回N）收到了2个反对的“赞成票”。
请详细说明为什么这不是一个好建议。

我想知道为什么我提出的使其动态化的建议（仅从B / G设置返回N）收到了2个反对的“赞成票”。
请详细说明为什么这不是一个好建议。

我认为，如果有人启用了此选项，他就已经在拼命地寻求更高的稳定性，并且知道这对他的AP设置意味着什么。
我更喜欢静态解决方案，因为当我选择仅B / G选项时，我绝对不希望自己处于使用B / G但又没有使用B / G的情况。
但是，由于我的节点无论如何都在重新引导（尽管很少重启），所以我很想为与新内核有关的问题提供一个真正的解决方案。

我明白了，但是当用户不知道设置的作用并最终遇到无法访问的节点时，您还必须理解该问题。
因此，在切换回N支持之前，它应该具有较大的阈值。
例如，损坏的插件的后备版本为：
重启失败10次后，它将禁用1个插件或控制器，以查看重启是否成功。

类似的东西也可以应用于wifi连接。
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

因此，显然已经实现了仅在wifi_connect_attempt > 10时才允许N。
一旦成功尝试连接到wifi，此计数器将重置为0。

这是可以接受的解决方案吗？

嗯，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

因此，显然已经实现了仅在wifi_connect_attempt > 10时才允许N。
一旦成功尝试连接到wifi，此计数器将重置为0。

这是可以接受的解决方案吗？

好吧..我会说是的（希望很快会发现2.5.0中的错误）。

仅关于设置B / G的反馈。
我刚刚将测试固件安装在最近每20分钟重启一次的设备上。 在用-72dBi将其连接到N之前。 那应该是一个足够好的信号，不会断开连接。 我正在使用具有-105dBi接收功能的企业级AP。 因此，它永远也不应放弃频道。

经过测试FW几个小时后，到目前为止，尚未进行任何重置。
我将继续运行并进行报告。

PS：我同意这与N有某种关系。
PSS：我正在运行20个ESP-07节点，这些节点已升级到4M。 耗时，但需要重新刷新时还清。

我有120多个节点都在GN（mega-20190202）上运行，没有任何问题。 他们都报告要连接到N

@ jimmys01有多少个节点正在连接到同一AP？
那个AP的品牌是什么？ （Mikrotik？）

它们几乎都连接到不同的AP（每个酒店房间一个）。它们具有一个开关（PIR传感器），HTU温度和湿度传感器以及IR指示灯。
AP品牌是Mikrotik。
设置如下：
国家设置
控制通道：20Mhz
乐队：GN
扩展频道：禁用
身份验证类型：仅WPA2 PSK
加密：仅适用于aes ccm
组加密：aes ccm
Groyp密钥更新：00:01:00

仅关于设置B / G的反馈。
我刚刚将测试固件安装在最近每20分钟重启一次的设备上。 在用-72dBi将其连接到N之前。 那应该是一个足够好的信号，不会断开连接。 我正在使用具有-105dBi接收功能的企业级AP。 因此，它永远也不应放弃频道。

经过测试FW几个小时后，到目前为止，尚未进行任何重置。
我将继续运行并进行报告。

PS：我同意这与N有某种关系。
PSS：我正在运行20个ESP-07节点，这些节点已升级到4M。 耗时，但需要重新刷新时还清。

不幸的是，经过一段随机的时间后，该单元继续复位。 1-4小时之内。
仅B / G固件无法解决我的问题

我想知道为什么我提出的使其动态化的建议（仅从B / G设置返回N）收到了2个反对的“赞成票”。
请详细说明为什么这不是一个好建议。

假设wifi本身由于外部/环境情况而关闭了一个小时。 我的节点切换到N并再次变得高度不稳定（我的应用程序对重新启动很敏感-wifi不一定要100％的时间都在那儿，但是节点本身应该一直在运行）。

我希望为我的节点配置一个避免不稳定的配置，并且永远都不要连接到N上。

将其移至主要设置时，我建议默认情况下此选项为开。

作为解决方案，我们可以将其默认设置为回退模式（B / G-then-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次重新连接。 现在几个月以来，除了在AP上禁用PMKID之外，我再也没有任何连接问题。 较新的内核可能对wifi设置更加挑剔，或者我不知道该怎么办。我也使用2A电源运行所有这些内核。 我们计划在下个月再部署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中存在一个错误，该错误使Web服务器停止响应并使节点崩溃。
修复后，将再次有2.5.0核心版本。
在最后一个夜间构建中，其中包含一个核心2.6.0 alpha，它本质上是来自核心库github的最新代码，因此您可以自己看看。

在两个模块上运行B / G以来，自2.6.0起仅运行了4天，而第一个模块进行了重新引导。
重置原因是通常的“硬件看门狗”。
由于仅“ B / G”模式处于活动状态，因此我观察到的是运行3..5天后才能进行重置。

也许还可以比较wifi断开连接的数量，因为这些断开连接似乎与崩溃有关。

两个模块都在地窖中，距离Mikrotik AP仅2..3m。
我只是检查了运行相同固件版本的第二个模块，它显示0重新连接和4d02h正常运行时间（自闪烁以来没有重新启动）。
我高度重视另一个模块，它进行了重置。 在重置之前也有0次重新连接。

关于在两个测试模块上配置的任务：
重置后的模块具有配置的12个DS18B20传感器，它们每120秒将其值发送到FHEM服务器。
到目前为止尚未重置的模块仅配置了两个gpios，它们每120秒将其值发送到同一FHEM服务器。

因此，AP（Mikrotik）是相同的，距离（2..3mm）是相同的，FHEM服务器是相同的-仅具有12个温度传感器的模块肯定比具有2 gpios的模块更频繁地复位。

在我的节点上，发生这种情况的主要原因是当fhem太慢而无法响应或无法访问时，因为我定义了最大重试次数100，然后节点重新启动（然后还显示了手动重新启动）。

在我的节点上，发生这种情况的主要原因是当fhem太慢而无法响应或无法访问时，因为我定义了最大重试次数100，然后节点重新启动（然后还显示了手动重新启动）。

重试次数超过100时，为什么节点应该重新启动？
（我已将重试次数设置为0进行测试）

工具->高级->连接失败阈值

确保模块上的wifi由于某种原因而阻塞，一段时间后会重新启动...

带有“重试”的意思是FHEM控制器设置中的“连接失败阈值：”而不是“最大重试：”。
我已将连接失败阈值设置为0。

顺便说一句：我第一次遇到一个节点，即使“仅B / G”处于活动状态，它也卡在4WHS超时问题中……迄今为止从未有过（自编译，2.5.0内核）……。如果这只是一个巧合，我将继续观察。

请注意，很快会有一个核心2.5.1会将使用过的SDK还原为SDK2.2.1，因为SDK3.0.0存在很多问题
这也可能会改变节点在wifi上的反应方式，也许可以再次与Core 2.4.2媲美。
不确定核心2.5.0中包含哪些修复程序可能会解决我们面临的其他一些问题。

@ chunter1关于您拥有的节点。
似乎重新启动的那个正在向控制器发送更多的消息，因此从统计上来说，它有更大的机会尝试发送某些东西，该东西在过程中停滞了。

@ clumsy-stefan您可以在Github上测试当前代码吗？ （或最新版本）

我对如何执行与网络相关的活动进行了一些更改。

你是这个意思吗？

ESP_Easy_mega-20190227_test_core_260_sdk3_alpha_ESP8266_4M.bin

几乎是昨晚的任何版本。
我还使用SDK2为核心2.6.0添加了“正常”版本。
Core 2.6.0 SDK2现在可以在多个节点上运行，并且其中只有一个硬件监视程序，它的资源非常低（运行大量的高内存插件），并且其中一个闪存可能已用尽（应该丢掉那一个，因为它已经进行了1000次固件更新）

@ TD-er我大约在6个小时前从git编译并安装到2test节点上..但是由于我的互联网访问仍然非常有限，我大概只能在24小时内报告回来，所以...

我已经在Mikrotik路由器上使用“强制B / G模式”测试了最新的固件，到目前为止，它似乎工作稳定。 将会回报。

@ TD-er一个问题：设置为“强制B / G模式”时，退回到N模式的规则是什么？

@ giig1967g
如果仅使用_B / G_无法与AP连接10次以上，它将恢复为默认的BGN模式。

因此，如果AP脱机一段时间后，它将以N模式连接。
如果这似乎是一个真实的问题，我可以尝试将其设置为仅每10次尝试一次，但是我必须确保在尝试后备ssid时，它也可以尝试该操作。

嗨@ TD-er
我认为回退是一个坏主意。
看这种情况：我的单元被Mikrotik强制进入B / G模式。
由于某种原因，我的Mikrotik脱机（更新，重新启动等）。
如果mikrotik再次出现，则ESP将以N模式连接，而我失去了装置的稳定性。

换句话说，如果我设置了强制B / G模式并且连接失败，则它应成为AP（192.168.4.1），但不应该回退到N模式。 后备可能性给用户带来了错误的期望。

不要误会我的意思，后备功能很好地测试了更改的有效性，但是现在已经证明它可以解决问题（至少到目前为止是这样），应该删除后备功能。

我同意@ chunter1评论： https :

那么您如何看待下一个场景。
只要有可能仅使用B / G连接到给定的AP，就会设置一个额外的标志以不再提供备用。
如果其中某些设置（仅B / G或其他AP设置）发生更改，则将再次启用后备功能，直到成功连接到给定的AP。

编辑：
对于后备广告，我指的是那些额外的设置，而不是“后备广告SSID”

换句话说，回退仅在第一次成功连接到AP之前保持活动状态，然后将其删除。 在这种情况下，在系统页面中查看wifi模式会很有帮助。
即使设置了Force B / G，即使我仍然希望避免回退到N，这也是一种可行的解决方案。
我了解用户可能会犯错，但随后用户可能会输入错误的SSID并且在任何情况下都无法访问该设备...

另一个问题：在当前实施中，该单位将在哪种情况下成为AP？
因为在我看来，该单位将尝试B / G 10次然后尝试N，但最终会放弃并成为AP吗？

是的，AP模式仍然保持活动状态，同时仍在测试以连接到给定的AP。
也许我们还应该添加对正常运行时间的可选检查，并且仅允许在引导节点的前10分钟内启动AP模式。
只是为了增加安全性，并排除AP模式可能会影响ESP无法访问给定wifi网络的可能性。

而且，我们应该继续关注项目的“轻松”部分。
这意味着适当的默认设置，不会提供大量的设置，但让专家可以选择全部设置。
这也意味着应该为经验不足的用户提供适当的后备支持。
特别是对于仅B / G设置。 我想90％以上的ESPeasy入门人员都不知道802.11B / G / N之间的差异，因此，如果他们遇到问题，可以通过使用后备方法很好地解决问题，这可能会导致他们寻找其他项目。
我也理解为什么这种后备不应该给人一种错误的“稳定性”感，所以我真的理解为什么当前的实现有改进的余地。 但是，如果将“首次连接尝试成功=>禁用回退”设置为自动，则对于经验丰富的用户来说也很理想。 （根据我的经验，他也犯了愚蠢的错误；）

我同意应该更清楚地说明使用了哪种连接设置。

了解。
所以，prosal是：
该单位的靴子。
N-fallback标志设置为true。
如果设置了FORCE B / G，它将尝试10次连接到B / G中的wifi AP。
如果可以连接，则将N后备信号中断设置为false。
如果无法连接，则尝试N模式。

请同时考虑将Force B / G设置为：电源故障的这种情况。
ESP和Wifi路由器已关闭电源。
然后电源恢复供电，ESP的启动速度比wifi路由器快。
在这种情况下，可能会发生10倍的wifi AP仍未监听的情况。
因此，该设备将尝试N模式，并最终成功。
（有经验的）用户将不知道该连接处于N模式，并认为它处于B / G模式且缺乏稳定性。

我不想坚持，但实际上，这种硬件和冻结问题自一年以来一直在持续。 既然您在社区的帮助下找到了一个可行的解决方案，我强烈建议您确保它仍然适用。 没有经验的用户设置“强制B / G模式”的风险要小于他设置错误的SSID的风险，其结果是：没有访问接入点的权限。

建议：
为了确保不太熟练的用户不会犯错，为什么不在“测试B / G模式”中添加按钮。 如果成功，它将启用“强制B / G模式”，否则将保持禁用状态。

在这种情况下，经验不足的用户将知道他们在做什么，经验丰富的用户将确保在设置ForceB / G模式后，它不会回退到N。

你怎么看？

你可以

不仅可以启动，还可以在设置中禁用后备选项并保存。

好。 然后，手动检查比自动检查更为合适。 你不觉得吗

是的，我将首先添加一个简单的选中标记以禁用替代。
但是稍后应该使它更具动态性，以帮助我们减少“专家”的错误：）

好

版本2019_02_16现在已运行9天，没有重新启动（强制为B / G）。 昨天它开始重新启动。 硬件看门狗强制执行两次。
一段时间后，该单元不再可用。 WLAN路由器的切换无济于事（尝试了3次，最多30分钟）。 通过切换电源保险丝来重启ESP也无济于事。
我不得不再次关闭WLAN，然后才直接通过192.168.4.1连接到ESP以获得访问权限

我完全不知道发生了什么

@kischde您使用哪种访问点？
昨晚，我在尝试安装新的AP时遇到了类似的情况。
我试图安装MikroTik AP，并且一切正常，直到需要重新连接ESP。
通过MikroTik的Web界面，我可以看到该节点已连接到WiFi，但没有收到IP地址。
即使当我尝试将其连接到手机的热点时，我也可以重新启动ESP，但它会重复此行为。
仅当我将主AP配置设置为另一个AP时，它才开始像应该的那样进行连接。

请注意，未重新引导节点即可实现此目的。

与我拥有的另一台MikroTik相比，在该AP上设置为“不正确”的一件事是它的“距离”设置为“室内”。
我将执行更多测试，以查看有什么区别，但是像前面讨论的那样，似乎是对数据包进行答复的超时设置。
我可以想象ESP确实需要一些时间来响应DHCP请求，对于此设置来说可能太短了。

我使用的是Swisscom AP（瑞士电信提供商的AP），但是我在不同的地方都遇到过同样的问题，例如MikroTik的家伙。 因此它可能具有相同的芯片组，但是我无法在设置中进行太多更改，例如那些扩展设置。
在重新上电之前，我也尝试像您一样以与您相同的方式连接手机。
我使用固定IP，没有DHCP
我现在切换到实际的2019_03_05，会看到发生了什么...

您最近是否更改了WiFi设置？
例如，MAC地址为BB：BB：BB：BB：BB：BB的SSID的另一个AP的位置1上的MAC地址为AA：AA：AA：AA：AA：AA的接入点
我感觉到ESP的某些地方还剩下一些设置，我们不存储它们。

我还将尝试在NonOS文档中查看如何在更改WiFi设置时有效清除这些内容。
同样在我的测试中，使用两个以上的SSID似乎非常有用。
我还将尝试为此添加更多字段，或者甚至允许在SPIFFS中存储一些加密文件，以几乎无限量地存储WiFi AP。

您最近是否更改了WiFi设置？

不，因为我只有一个AP，所以这不是IMO

好。 很高兴知道。
由于我还不知道是什么原因造成的，因此我尝试消除尽可能多的未知数。
因此，您只需要做的一件事就是再次添加wifi设置。

不，甚至更少
我被迫通过192.168.4.1直接连接到esp（禁用了AP）
然后，我检查了所有内容，但没有发现任何异常情况。因此，我尝试了一下，然后重新启动我的AP，而不是重置ESP，然后再次运行。 因此，IMO我只需要强制执行“正常/其他” WLAN连接即可。
顺便说一句，我还看到它连接到了AP，但是也没有分配IP地址，但是它是静态的

嗯，我一直在玩，将5个节点连接到正在玩的MikroTik。

一旦我设置了“硬件碎片阈值”（只是“展开”该选项），ESP节点就不再能够接收任何IP地址。
此设置的默认值为256。如果将其设置为1600（将适合完整的MTU），则所有节点将获得IP地址并继续工作。

当节点能够通信时，这将显示在MikroTik UI中：

当他们无法发送/接收任何数据（但已连接到WiFi层）时

@ TD-er您是否看到新esp8266内核中有一个名为LWIP_FEATURES ，我认为它将激活IP重组...可能在您的构建中未定义？

看到这里： https :

还设置了IP分段支持：
https://github.com/esp8266/Arduino/blob/192aaa42919dc65e5532ea4b60b002c4e19ce0ec/tools/sdk/lwip2/include/lwipopts.h#L756 -L763

嗯，不确定默认值是多少。
Doxygen文档第一行中给出的数字是否为默认值？

我不知道...我只知道，您可以在Arduino IDE的平台定义文件中选择是否要包含和定义它。

我一直认为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 （与标签相反，有点直观）。