ESPEasy 🚀 - [バグ] [WiFiの安定性]レイヤー2が切断されたときのESP例外3/29

同じ問題があるようです。時々私のespはwifi接続を失い、wifiから何時間も「失われた」ままになります。ウォッチドッグのおかげで、再起動してWi-Fiに再接続する必要がありますが、そうではありません。コールドブートは問題を解決します。

wolverinevn 2018年11月01日

@wolverinevnによって説明された最後のことは、私がここでも起こっているのを見たことです。

TD-er 2018年11月01日

＃1957で説明したように、これらの奇妙なWiFi /ネットワークの問題の多くは、このレイヤー2の不安定性に起因すると確信しています... APをいくつかの増加したタイミングに変更する前に、あらゆる種類の奇妙な動作を確認しました...

clumsy-stefan 2018年11月01日

＃1957で説明したように、これらの奇妙なWiFi /ネットワークの問題の多くは、このレイヤー2の不安定性に起因すると確信しています... APをいくつかの増加したタイミングに変更する前に、あらゆる種類の奇妙な動作を確認しました...

あなたが解決策を見つけることを願っています。私のNodemcuの1つがハングし、理由もなく今まで5時間ルーターから消えました。ウォッチドッグから回復できることを願っていますが、何も起こりません。今すぐ手動で再起動する必要があります。とてもイライラします！

wolverinevn 2018年11月02日

@wolverinevnは、ノードに再度アクセスできるようになったら、tools => Advancedに移動し、「接続障害のしきい値」を0以外に設定します（タスクの数に応じて、50〜100の値をお勧めします）。これは実際には問題を変更しませんが、ノードが再起動して再接続する可能性が大幅に高まります。

他の回避策は、アクセスポイントのいくつかのパラメータを微調整できるかどうかです。これは、実際にどのタイプのAPを微調整できるかによって異なりますが、...

clumsy-stefan 2018年11月02日

👍2

@ clumsy-stefan ESPeasyのデフォルトもこのレベルに設定する必要がありますか？

また、この値をsysinfoページに表示して、ルールで使用できるようにする必要がありますか？

TD-er 2018年11月02日

@ TD-erデフォルトでそれをあるレベルに設定することは、それが低すぎなければおそらく悪いことではありません（接続が失敗することは常に起こり得ます）。

問題をデバッグするとき、これがどのように行われるかを考えました。現在、接続が失敗するとカウンターが増加し、接続が成功するとカウンターが減少します。接続が成功したらすぐに0にリセットする方が論理的かどうかを考えましたが、それは少しイデオロギー的な質問だと思います。

その数の問題は、10個のタスクがあり、それぞれのタスクの再試行回数が10回で、再送信の遅延が100ミリ秒である場合、実際の通信に問題があると再起動が非常に速く発生することです（約10秒以内に100回再試行）。。

たとえば、常に5つの通信が失敗し、1つが成功した場合、接続障害は継続的に増加します。これが常に発生する場合は、すべてのデータが配信されたとしても、遅かれ早かれノードを再起動します。

しかし、私が見ている主な問題は、ノードがレイヤー2の接続が実際になくなったことを認識しておらず、データを送信し続けていることです（私は推測します）。これに加えて、今夜私が気付いたのは、wifi接続がない場合、syslog（およびNTPなどの他の通信）はどうなるのでしょうか。これもやめますか？これは、レイヤー2がなくなったときにノードが突然100％CPUにジャンプする理由を説明している可能性があります。おそらくこれ以上タスクデータは送信されませんが、UDP Syslogパケットを取り除こうとしますが、推測することはできません...

申し訳ありませんが、2つの簡単な質問の長いテキスト...要するに：
デフォルトレベル：はいデフォルトで最大（100）程度に設定します...すべてが問題ない場合は害はありませんが、ユニットは再びアクセス可能になります...
sysinfoページとルール：いいえ、なぜこれを動的に変更する必要があるのですか？それは緊急の価値です...

clumsy-stefan 2018年11月02日

@ clumsy-stefanすでに50に設定しています。待ちましょう。 ;）

wolverinevn 2018年11月02日

@wolverinevnうーん... 50は、タスクの間隔と再試行の数に応じて非常に速く発生するはずです（5〜15分）...これが役に立たない場合は、ノードが実際にはフリーズしていないと思いますが、それは可能です。 tネットワークに再接続します。 WDを再起動した後でもこれがありました。ノードがAPモードに移行しようとしているかどうかを確認できますか？ノードのAP-WLANが表示されますか？

clumsy-stefan 2018年11月02日

sysinfoページとルール：いいえ、なぜこれを動的に変更する必要があるのですか？それは緊急の価値です...

%conn_fail%ようなシステム変数を使用してルールを検査し、それをsysinfoページのwifi再接続数の横に表示することを意図していました。
結局のところ、それはパフォーマンス統計値です

TD-er 2018年11月02日

％conn_fail％のようなシステム変数を使用してルールを検査し、それをsysinfoページのwifi再接続数の横に表示することを意図していました。結局のところ、それはパフォーマンス統計値です

ああ、はい、同意します、それは理にかなっています！それはまた、問題＃1993に少し関連しています。多数のシステム/パフォーマンス変数を（限られた利用可能なタスクを無駄にすることなく）コントローラーに定期的に送信するプラグインがあると、本当に素晴らしいです！

clumsy-stefan 2018年11月02日

@wolverinevnうーん... 50は、タスクの間隔と再試行の数に応じて非常に速く発生するはずです（5〜15分）...これが役に立たない場合は、ノードが実際にはフリーズしていないと思いますが、それは可能です。 tネットワークに再接続します。 WDを再起動した後でもこれがありました。ノードがAPモードに移行しようとしているかどうかを確認できますか？ノードのAP-WLANが表示されますか？

9つのタスクがあり、そのうち3つはダミーとMQTT_importです。ルールはセンサーの計算と読み取りで少し忙しいと思います。数分ごとにルールを呼び出すことでmqtt_publishを制限しようとしました。負荷は約29％です。
覚えているように、前回今朝凍結されたとき、EspeasyのAPが見つかりません（AP_WLANがAPモードで動作していることを意味する場合）。
私のセットアップ（ネットワーク、ESPの場所）は、3月にリリースされた2.3または2.4を実行している別のNodemcuでうまく機能していました。

_稼働時間は7時間20分、RSSIは-71dbm、私の周りにはいくつかのWi-Fiがあります。
最後の切断理由：| （200）ビーコンタイムアウト
再接続数：| 35_

wolverinevn 2018年11月02日

@wolverinevnこの問題の問題は、完全にランダムに発生することです。私は最大30のノードを実行していますが、問題が発生したノードもあれば、再起動されなかったノードもあり、APモードに移行したノードもあります...

これは、ノードがどれだけビジーであるか、空気がどれだけビジーであるか（たとえば、wifiデバイスの数）、およびAPが特定の条件（レイヤー2のackを見逃すなど）を実際に処理する方法の組み合わせのようです...

したがって、アプリケーション（ESPEasy）内でこの状態を確実に検出して対処する方法が見つかるまで、「実際の」解決策はありません。

clumsy-stefan 2018年11月02日

👍2

@wolverinevn PS：たまたまmikrotik APを使用していませんか？

clumsy-stefan 2018年11月02日

@wolverinevn再接続の数について（編集中）
約8時間で35回の再接続が多いです。
私はここでノードを数日間実行していますが、再接続はほんの一握りです。
最も安定したものは、現在20日11時間46分実行されており、再接続は1回だけです。

接続済み| 19d22h33m
-| -
最後の切断理由| （202）認証に失敗する
番号の再接続| 1

TD-er 2018年11月02日

@wolverinevn PS：たまたまmikrotik APを使用していませんか？

いいえ。Padavanファームウェア（ASUSの一種）を実行しているルーターを使用しています。

@ TD-er私はそれを知っていました。理由を調べています。近くの降圧モジュールからのノイズである可能性があります。もう1つは、2時間後に再接続が0になります。

wolverinevn 2018年11月02日

いいえ。Padavanファームウェア（ASUSの一種）を実行しているルーターを使用しています。

残念ながら、私はこのFWをまったく知りません...レイヤー2パラメーターを微調整する機会はありますか？フレームACKタイムアウトなどのようなものですか？ある種の「距離」設定？

clumsy-stefan 2018年11月02日

@ clumsy-stefan残念ながら、そのようなものは見当たりません。

wolverinevn 2018年11月02日

@ clumpsy-stefanユニットは昨夜2回再起動され、50の障害しきい値が設定されました。良いニュースは、もう凍結されていないということです。今日は、ハードウェアの設定を少し変更して、wifi接続を改善しようと思います。

wolverinevn 2018年11月03日

同じAPに接続された同じ部屋の3つのWemosユニット。
過去16時間ほどで再接続し、
ルールあり：WiFi＃Connectedの場合...。

26回のWDの再起動と104回の再接続：
muc21_capture

9回のWDの再起動と32回の再接続
muc19_capture

2WDの再起動と40回の再接続
muc14_capture

すべてに50の障害しきい値が設定されています

Domosapiens 2018年11月04日

@ Domosapiens ＆ @ wolverinevnもう1つ試すことができるのは、APのgroup-key-timeoutを増やすことです（そのようなオプションがある場合）。通常、それは約5分です。あなたは30分に増やすことを試みることができます。または1時間でさえ、それが悪化するかどうかを確認します（IoTが含まれている場合は想定していませんが、超高セキュリティネットワークにない限り）...

clumsy-stefan 2018年11月05日

@ TD-er

最も安定したものは、現在20日11時間46分実行されており、再接続は1回だけです。

現在、3日以上稼働しているユニットと、1日以内に再起動したユニットもあります...

グループキーの再キーイングに関していくつかの問題が発生しました。どういうわけか、コアの新しいバージョンでは、キーの再生成がタイムアウトになる可能性があります...しかし、アプリケーションはこれに基づいて動作し、高負荷の応答しないモードに入らないようにする必要があります...しかし、私はそうではありませんどこで失敗しているのかを確認してください。

clumsy-stefan 2018年11月05日

@ clumsy-stefanあなたの提案に感謝します。
dd-wrtルーターにパラメーターが表示されます。値が3600（秒単位）の「キー更新間隔」。
だからそれは大丈夫ですか？

キーの再生成でタイムアウトが発生する

それは1時間ごとの再接続imhoだけを説明するでしょう。
素晴らしいルール機能_WiFi＃Connected_のおかげで、これを見ることができます。
古いバージョンがこれでどのように機能したかはわかりません。
すでに長い間隠された問題？

Domosapiens 2018年11月05日

5分からグループキーの更新を設定した後。 1時間まで、ユニットははるかに安定して動作します。 40台のクライアントが1つのAPに接続され、5分ごとに実行されていると思います。キーを再生成すると、空気が少し忙しすぎました。その後、フレームACKタイムアウトを再び減らすことができ、ユニットの応答性が向上しました。また、これらのパラメータを変更した後の「接続タイムアウト」も少なくなりました。

@ TD-それでも、この「グループキーのタイムアウト」とその後の「関連付けの失敗」は、アプリケーションでキャプチャして処理する必要があると思います。キーの再生成を試みている間、ユニットがキューに入れられたメッセージをコントローラー/サーバーに送信しようとし続けているように感じます。これにより、ユニットの速度が遅くなり、再キーイングが失敗します...したがって、レイヤー2で切断されます。

大まかなアイデアですが、私はまだそれを実際に固定しようとしていますが、それは私が今までに得ることができた最も近いものです。

clumsy-stefan 2018年11月05日

@ TD-er jsut今度は、再接続試行の無期限のループに入り、常に期限切れになるノードを再び経験しました（以下のログを参照）。興味深いのは、接続されていないことを明らかに認識し、データをコントローラーに送信しようとしないことです。つまり、「失敗した接続試行」はそれ以上増加せず、したがって失敗した接続制限に達することはありません。

また、負荷は常に100％を示します。そのため、実際にハンドシェイクを実行するには常に遅すぎるため、再接続に成功しないと思います。...私には尻尾のように聞こえます...メモリがゆっくりと減少するまで（ memがないのでクラッシュすると思います）...

＃2073でテストして、この状況が再び発生するかどうかを確認します...ただし、2つのシリアル接続ノードで発生することはめったにないため、実際に何が起こっているかを追跡できます...

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

clumsy-stefan 2018年11月27日

rssiに接続するのは難しい-80

uzi18 2018年11月27日

ノードESPが接続されていない場合、RSSI値は信頼できません。同じノードは、接続時に-70未満になります。ディープスリープノードでは、値を送信するときに「接続されていない」デフォルトの+31が表示されます。
再起動後、問題なく実行されます...（移動せずに...）上記を読んだ場合、APのパラメーターを微調整すると再現可能なレイヤー2の問題です...。

PS：あなたはそれを自分で試すことができます！ jsutは20〜30個のノードを接続し、グループキーのタイミングを5分に下げます。そして、7のようなものへのフレーム応答しきい値...何が起こるか見てください！

clumsy-stefan 2018年11月27日

layer2の問題については間違った場所だと思います。esp8266コアで問題を埋めるか、nonossdkプロジェクトで問題を解決する必要があります。
しかし、ここで叫ばないでください

uzi18 2018年11月27日

これはESPeasyでのみ発生し、私が試した他のタイプのファームウェアでは発生しません。ある時点でノードがビジーになりすぎて、コアにキーの再生成を行うのに十分な時間が残されていないと思います（すべてが何度も説明されています）ので、デバッグと説明を読んでください...
しかし、私は同意します、あなたは実際に答える必要はありません...
PS： @ uzi18は、30個のノードを同時に正常に実行したことがありますか？

clumsy-stefan 2018年11月27日

@ TD-er： ESPEasyWifi.ino行650〜669で、switchステートメントのデフォルトの一致がスイッチから外れるため、 WiFi.status()がWiFi.status() tryConnectWiFi()はtrue返します。必ずしもWL_CONNECTEDある必要

これを変更してtrueを返すのWiFi.status()実際にWL_CONNECTEDを返した場合にのみ、私が直面しているレイヤー2の切断/例外の問題の少なくとも1つを解決します。

どう思いますか？
何かが足りないのですか、それともWiFi.status()が？WL_CONNECTED`でないのにtryConnectWiFi()返されるのはなぜですか？

clumsy-stefan 2019年01月04日

👍1

@ clumsy-stefanまだWiFiコードを掘り下げているのを見て良かったです。

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

この機能の最初のアイデアは、WiFi接続シーケンスを開始することでした。
たぶん、その機能はそれ以来のすべての変更を通して少し変更されました。
しかし、あなたはここで何かをしているかもしれません。
ステータスが接続されていることを返した場合にのみ、（その関数の最後で） return trueへの適切な変更である可能性があると思います。

あなたが直面している他のレイヤー2の問題と思われるものを説明できますか？

TD-er 2019年01月04日

他の例外がいつ発生するかを正確に言うことはできませんが、ステータスが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 2019年01月04日

@ clumsy-stefanこのステータスは、Arduinoのwifiステータスを中継できないためです。そのため、@ TD-erはESPEasyステータスを導入しましたが、コード内のすべてのステータスが適切にチェックされているかどうかを再確認することもできます。

uzi18 2019年01月04日

このwifiステータスがコア2.5.0で修正された可能性があるため、私たち自身のステータスが廃止された可能性があります。
それはWiFiコードをかなり複雑にし、エラーが発生しやすいので、それは素晴らしいことです。

編集：
私はあなたが与えたこのエラーを見ています：
Fatal exception 9(LoadStoreAlignmentCause):
コア2.5.0での最近の修正の1つは、 IPAddressのコンストラクターに関するものです。これにより、特定のバイトシーケンスのアラインメントが32ビットアラインメントされていない場合の問題が修正されます。
多分これは似たようなものですか？

TD-er 2019年01月04日

これは、ESPEasyステータスがArduinoステータスと常に同期しているとは限らないという私が推測していることの1つです。特に、レイヤー2での一時的な切断（WiFiリーキーなど）は、実際には処理/実現されていない可能性があります。

もう1つは逆の可能性があります。それは、ESPEasyが切断されたと見なして再接続を試みますが、コアはまだ接続されているため、例外が発生することです。しかし、それをまだ証明することはできません...

配置については、はい、できますが、現在これを釘付けにすることはできません...

したがって、現在私が確信しているのは、 tryConnectWiFi()のリターンコードが実際の接続ステータスと一致するか、少なくともWL_CONNECTEDです...

clumsy-stefan 2019年01月04日

@ 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

私にとって、最後の2行は、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でクラッシュすることがあります...したがって、切断からどれだけ正確に回復するかは、ある種の競合状態のようです！~~ 私のせいで、 onDisconenct()コールバックにaddLog()ました...

clumsy-stefan 2019年01月04日

それは多かれ少なかれ常に同じ状況です。 4ウェイハンドシェイクが失敗した後（rekeeying）、それはもう回復しません...これの回復を強制する方法がわかりません。

少なくとも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

clumsy-stefan 2019年01月05日

@ TD-er tryConnectWiFi()は、接続が成功したかどうかにかかわらず、 trueまたはfalseを返します...しかし、 WiFiConnectRelaxed()実際にはこれをチェックしません....。

この機能はどういうわけかイベントベースのWiFiの前からですか？その関数の最後の2行に到達することはないようです...

clumsy-stefan 2019年01月07日

はい、それはイベントベースのwifiの前からのある種の残り物でした。
そのWiFiコードは本来あるべき構造になっていないので、もう一度よく見ることを検討する必要があると思います。

TD-er 2019年01月07日

わかりました... 4wayハンドシェイクタイムアウトが原因で正確に何が起こるのか、ノードが再接続しない理由をまだデバッグしています...しかし、私はまだ暗闇の中で少し突っついていると思いますが、ここで小さなビットを見つけてでも、合計することができます。

clumsy-stefan 2019年01月07日

もう1つの小さなものはWifiCheck()です...そこでレイヤー2接続のチェックは、IPが無効になった場合にのみ実行されます（たとえば、すべてのオクテットが0です）。これにより、レイヤー2が切断（または再）接続/ハンドシェイクなどされている状況が発生する可能性がありますが、IPはまだ有効期限が切れていないため（DHCP）有効です。これがおそらく、「DCHPの更新が失敗した可能性があります」が、リースが実際になくなった長い時間の後にのみ発生する原因です...しかし、私はまだこれを確認しています...

clumsy-stefan 2019年01月07日

また、 wifiCheck() 、 WiFiConnected() 、およびconnectionCheckHandler()あり、これらはすべて何らかの接続チェックを実行し、特定の条件下でresetWiFi()と同様に相互に呼び出します。。特にconnectionCheckHandler()は、 mqtt_reconnect_count > 10場合にのみ呼び出されるようです。では、MQTT以外の環境ではどうなりますか？

PS：私はここで私の発見を文書化して、根本的なWiFiの問題を探しています...だから私はそれについての考えに満足していますが、必ずしも期待されていません...

clumsy-stefan 2019年01月07日

👍1

どこかにある種の不思議な競合状態がなければなりません。 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

clumsy-stefan 2019年01月10日

👍1

では、wifiイベントはプロセスを監視するためだけに使用し、自分でアクションを実行する必要はないのでしょうか。
これを変更すると、2.3.0およびおそらく2.4.0ビルドが使用できなくなります。

TD-er 2019年01月10日

いいえ、私はそれをしません...私のブランチでは、これらのケースが発生する頻度を減らすように思われるいくつかの（それほど邪魔にならない）変更をすでに行いました...

tryConnectWiFi() 、 WiFi.begin()呼び出しがWL_DISCONNECTEDを返し始めた後、 WiFi.begin() WiFi.status()チェックが終了します。ドキュメントによると、これは「モジュールがステーションモードで構成されていない場合」を意味します。 WiFi.begin()呼び出す前に、なぜこれが発生するのか、または実際にespを明示的にAPモードにするのに役立つかどうかを調べようとしています

だから私はまだこれらの失速が起こる「本当の」根本的な問題を見つけたいと思っています...もしそうなら（指が交差した）私はあなた（そして他の人）がレビューするためにすべての変更でPRをすることを提案します...

clumsy-stefan 2019年01月10日

WiFi.status()が正しくない状況もたくさん見たことがあることをご承知おきください。
そのため、コアライブラリに修正が加えられ、WiFiを安定して動作させるためのすべての試みのどこかで混乱した可能性があります。
私はこれらの問題を自分で再現することができず、他のユーザーからの報告に基づいて行動しなければならなかったため、そのデバッグを行うのは非常に困難でした。
最近、WiFiに関しても悪い動作をしているモジュールがあるので、それが私のお気に入りのWiFiテストモジュールです。ただし、一部の部品が仕様から外れている場合、問題が悪化する可能性もあります。たとえば、電源、デカップリングコンデンサの欠落、（あまりにも）薄いPCBトレース、シールドの低下などです。

TD-er 2019年01月10日

確かに、私がハードウェアの問題を除外しているわけではありません。しかし、私は最大40のノードを実行しており、すべての異なる種類の電源、異なるボード、ブランドなどがあります...そしてある時点でそれらのほとんどは接続の問題に直面します...特にwifiカバレッジが弱いものやGPIOが使用されています。

そして、私は現在、デバッグを行う時間が少しありますが、それでも非常に面白くてやりがいがあります;）今では、接続、チェック、切断などのシーケンス全体がどのように機能するかを理解し始めています;）

ですから、問題がなければ、これらの接続の問題についてさらに深く掘り下げていきます。しかし、あなたは上司です。

clumsy-stefan 2019年01月10日

👍3

掘り続けてください:)
再現がほぼ不可能な切断の問題から解放されたいと思っています。
それらはすでに時間がかかりすぎているので、修正されれば本当に素晴らしいでしょう。

TD-er 2019年01月10日

平均して、約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 Easy | 情報|
----- | ----- |
ビルド：⋄| 20103-メガ|
ライブラリ：⋄| ESP82xxコア2_4_2、NONOS SDK 2.2.1（cfd48f3）、LWIP：2.0.3PUYAサポート|
GITバージョン：⋄| mega-20190110 |
プラグイン：⋄| 7 [通常] [Sonoff POW R1 / R2] |
ビルド時間：⋄| 2019年1月10日03：21：19 |
バイナリファイル名：⋄| ESP_Easy_mega-20190110_hard_SONOFF_POW_4M.bin |

0ki 2019年01月11日

これは古いバージョンでは問題ではありませんでした（まだチャネル14を使用でき、hidden-ssidネットワークを使用できる場合）。

0ki 2019年01月11日

WiFiチャネルは固定されていますか、それとも可変ですか？
Tasmotaのトラブルシューティングページを読んでいますが、WiFiチャネルを修正するよう強く勧めています。
チャネル14が使用できない場合は、すべての国でチャネル1〜11のみが許可されているため、地域の設定に関する問題がどこかで変更されている可能性があります。
また、チャネル1、6、および11は、実際には他のチャネルからの干渉なしに使用できる唯一のチャネルです。

TD-er 2019年01月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、...。

0ki 2019年01月12日

IPとDCSを修正しましたが、チャネルは過去に変更されていません。

Von：Gijs Noorlander [mailto：[email protected]]
Gesendet：Freitag、11。Januar2019 21:47
：letscontrolit / ESPEasy
Cc：購読済み
Betreff：Re：[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/AomgSxPjVKWrp0MSQTtbESKxFqaPVt90ks5vCPgxJp https://github.com/notifications/beacon/AomgS_fhHQnmg1AdpX11mVL9yNra8S_kks5vCPgxgaJpZM4YDivP.gif

NorbertRoller 2019年01月12日

Mikrotikのものは大きな力を与えますが、wifiのデフォルト設定でさえ正しくありません。

セキュリティ設定にtkipがないことを確認し、aesccm暗号化のみを有効にしてください
キーグループを入力してください30分または1時間のような更新
チャネル内のチャネル幅は20Mhzであり、どの意見でもBバンドをディッチし、G / Nのみを使用します。
拡張チャネルが無効
PMKIDを無効にするだけで（セキュリティについてヒステリックな場合に推奨）、Espveeeeryを不幸にするようです
国をwifi設定に追加します（または、使用しているAPの最大電力を確認し、送信電力を3下げます）。これは非常に頻繁にwifiのパフォーマンスを向上させます（直感に反して、私は知っています）

私は一般的に切断されていません（私がこのPMKIDのものを持っていたときを除いて）

とにかくAP設定を投稿することはとにかく洞察に満ちているでしょう:-)

jimmys01 2019年01月12日

それらは良いヒントです。私はネットワークに精通しており、 mikrotikの経験も豊富で、グループキーを除いてすべてを構成しました。

グループキーの更新はグループキーにのみ関係し、問題が存在するユニキャストキーには関係しませんが、実験のためにその設定をダウングレードしました。

0ki 2019年01月12日

@ 0ki Coolは、RouterOSの専門家がどこにいるのか知りませんでした。

jimmys01 2019年01月12日

これは明らかにESPEasyソフトウェアのバグであると結論付けました。左側の不正なクライアントを切断するRouterOSと一致する問題のある動作を右側に見ることができます。ご覧のとおり、無線スペクトルは明確です。
test

残念ながら、現時点ではESPEasyコードベースを詳しく調べる時間がありませんが、この悪いコミュニケーションと良いコミュニケーションの比較が役立つと信じています。
凡例：__ red-アクセスポイント| 青-espeasy | 緑-IoTネットワーク上の別のデバイス__
test2

ESP_easyは、何らかの理由で、アソック応答（左側のフレーム380）を受信した後、APモードに切り替え、4ウェイハンドシェイクを続行しないことを決定したと思います。 espeasymacaddressの変更にも注意してください。最初のオクテットが80から82に変更されます。

0ki 2019年01月12日

👍1

@ 0ki

これは明らかにESPEasyソフトウェアのバグであると結論付けました。

私もですが、どこにバグがあるのかわかりません。
切断状態に関するESPeasyの内部状態が真の状態と同期していないようです。
そのコードの記述でエラーが発生した可能性が非常に高いか、コアライブラリのバグです。

TD-er 2019年01月12日

「そのコード」とは具体的にどのファイルを意味しますか？ 1つか2つのファイルを指さすと、私はそれを見ることができます。

そうでなければ-今あなたはそれが起こる正確な瞬間を見るので、あなたがそれをもっとよく見ることができることを願っています。

0ki 2019年01月12日

私はこの問題を（今から約2か月間）掘り下げているので、それがESPEasyコード自体であるかどうかはもう完全にはわかりません。 ESPEasyとWiFiコア/ライブラリ間の相互作用の詳細...私のデバッグ/ログは、「切断」が常にグループキー交換/再キーイングの後に発生することを示しています。しかし、コールバックはキーの再生成のタイムアウト後、続いて認証が失敗した後にのみ呼び出されます...だから今のところ、ESPEasyは実際にキーの再生成を行うのに十分なCPU時間をコアに残していないと思います...今まで私はノードがこのrekeeyingノードまたはreauthモードにあるかどうかを確認する方法が見つからないため、十分なdelay()呼び出しを追加できるため、rekeeyingreauthが成功します...

clumsy-stefan 2019年01月12日

問題を時間的に特定するのを助けるために-それはうまく機能していました：

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への接続も問題ではなかったということです。

0ki 2019年01月12日

@ clumsy-stefan、そもそも切断の原因となる問題のキャッチを完全にサポートしていますが、正直なところ、wifi assocがドロップする理由はいくつかあるかもしれません。もちろん、グループキー交換は次のいずれかではありません。それら。

より差し迫った問題は、切断した後に再接続できない理由です。 4way HSのメッセージ2で返信するために、なんと5000msをespeasyに与えているので、タイミングの問題になることはありません。

0ki 2019年01月12日

問題は、キー交換が失敗した後にのみ切断されることだと思います...したがって、交換が実際に開始されるときは、コアにもっと時間をかける必要がある場所です...

ログを見ると、ESPEasyは、接続されていなくても（ノードへのpingが失敗しても）、かなり長い間接続されていると見なしますが、ノードはデータを送信しようとします（そして、明らかに接続が失敗します）...

私が完全に同意する2番目の問題は、切断されたとしても、完全に新しい接続シーケンスで再接続できないのはなぜですか...おそらくモジュールまたはコアが奇妙な状態でスタックしていますか？

編集：PS：4way HSは常に失敗するわけではないので（私は10分ごとに失敗します）、ESPEasyの状態/忙しさとHSが発生する時間の組み合わせのようです。

clumsy-stefan 2019年01月12日

私にできることは、WiFiを完全に切断し（モデムもオフにする）、予期しない切断が発生したときに完全に新しい再接続を開始することです。
それがこのスレッドにあるかどうかはわかりませんが、これらの問題の1つで、誰かがShellyの誰かのツイートで返信し、切断後にWi-Fiスタックを完全に再起動する必要があると述べました。

TD-er 2019年01月12日

@ TD-erそれは私が最新バージョンに入れたものでもあります。内processDisconnect()私は追加setWifiMode(WIFI_OFF);それが十分かどうかの、...現在、それは（約1時間以降）いくつかのテスト・ノード上で実行しているかわかりません...

clumsy-stefan 2019年01月12日

@ TD-erそれはクールなアイデアです。 gitリリースをプッシュしてください。フラッシュします。

5分前にコードベースの一部を読み始めたばかりなので、これは関係ないかもしれませんが、その時点でwifi_connect_attemptが0に設定されていることも確認してください。

0ki 2019年01月12日

うーん...各サブルーチン呼び出しの後にbackgroundtasks()にdelay(0)を追加すると、最初の問題が少し安定するようです（4way-HS）。偶然のタフかどうかわからない...
@ TD-ええと、 backgroundtasks()がある時点で実行をブロックしている可能性がありますか？

clumsy-stefan 2019年01月13日

一般的に言えば、タイミング統計が長い処理時間を示すあらゆる種類の異なる場所にdelay(0)を追加すると、4way-HSの処理が大幅に改善されるようです。私は今、rekeeyingの問題よりも多くのSW / HWウォッチドッグをキックしています（しかしまだいくつかあります）...症状があるので、それは本当にrekeeyingのようなことを実際に（非常に迅速に）行うのに十分なサイクルを取得していないコア/ wifi部分に関連していると思いますそしてAPは答えを待つのにうんざりします...

また、 client.connect()またはsendData()は、かなりの時間がかかる場合があります（最大2秒）。一部のドキュメントでは、何かに50ミリ秒以上かかる場合は、その間にdelay(0)を呼び出す必要があることがわかりました。ただし、ライブラリによって実行されるため、これらの呼び出しを分割することはできません。

コアには別のコールバックonStationModeAuthModeChangedもあります。これはおそらく実際の切断が発生する前にトリガーされるため、おそらく一見の価値があります。しかし、それはほとんど文書化されていません...誰かがこれを経験したことがありますか？

編集：APがキーの再生成を要求したときに行われている他のいくつかのこととの一致/競合状態のようです....しかし、ここでも単なる観察です...

clumsy-stefan 2019年01月15日

APによって送信されたこれらの要求がどのくらいの頻度で再送信されるかはわかりません。
通常、APからのビーコン信号は102.4ミリ秒ごとに送信されます。一部のタスクがそれ以上かかる場合、ESPはそのようなビーコンフレームの1つを見逃します。ですから、これがどれほど悪いかはわかりません。
ARP要求が失われることがあることは知っています。これにより、スイッチがそのMACアドレスにパケットをルーティングする方法がわからなくなり、ESPが到達不能になり、データ自体を送信できるという問題が発生します。

TD-er 2019年01月15日

ビーコンフレームが欠落していることは何もありません。とにかく私の隠されたネットワークを積極的に調査しているはずなので、ビーコンフレームさえ必要ないはずです。

0ki 2019年01月15日

私はWiFiの専門家ではありません。
私が理解したように、ビーコン間隔は、ESPがWiFiをリッスンしようとしている唯一の、ある程度保証された瞬間であり、その間は可能な限りスリープしようとします。

そして私が理解したように、「隠された」ネットワークと「隠されていない」ネットワークの唯一の違いは、SSIDがブロードキャストされていないことです。したがって、実際にはBSSID（APのMACアドレス）のみに基づいて接続しています。
これは、ESPが（非表示ではない）WiFiネットワークに接続するときに行うことでもありますが、唯一の違いは、前にスキャンを実行し、指定されたものと一致するSSIDを持つBSSIDを見つけようとすることです。
自動再接続を実行すると、スキャンを実行せずに、最後に認識されたBSSID +チャネルの組み合わせが最初に試行されます。つまり、接続する場合にのみ異なります。

したがって、私の知る限り、ネットワークに接続されている限り、ビーコンフレームもリッスンします。

TD-er 2019年01月15日

私はWiFiの専門家ではありません。
私が理解したように、ビーコン間隔は、ESPがWiFiをリッスンしようとしている唯一の、ある程度保証された瞬間であり、その間は可能な限りスリープしようとします。
そして私が理解したように、「隠された」ネットワークと「隠されていない」ネットワークの唯一の違いは.........。

ああ、それは私に非常に重要かもしれない何かを思い出させます。非表示のSSIDでESPを実行します
ちなみに、ノードの切断や再起動はまだありません（5分間のグループキーの更新を試みています）

jimmys01 2019年01月15日

停電のため、ノードの1つが12月5日に再起動されました。

これはその1つからです：

ご覧のとおり、平均して1日に複数の接続が切断されています。 AVM Fritzbox1750Eに接続されています

TD-er 2019年01月15日

ビーコンフレームはそれほど重要ではないと思います...切断後、通常のWiFi.begin()シーケンスが常に'(2) Auth expire'失敗する理由はまだわかりません。

唯一の兆候は、この時点でのCPU負荷は常に100％を示しており、コアがハンドシェイクを実行するのに十分な時間がないことを示唆しています...

clumsy-stefan 2019年01月16日

私の推測では、コアライブラリ（LWIPまたはArduinoまたはESP）に問題があり、wifiをリセットする必要があります。
したがって、wifiをオフにして、最初からやり直してください。また、これらの手順の間に待機して、バッファが空になるか、少なくともフラッシュされ、未処理の要求がアクティブにキャンセルされていることを確認します。

TD-er 2019年01月16日

@ TD-erこの変更をプッシュできるので、機能するかどうかを確認できますか？

0ki 2019年01月16日

最後の2つの投稿で議論された変更？
まだ実装されていませんが、今夜、コーディングしてテストビルドを作成することができます。

TD-er 2019年01月16日

はい、wifiをリセットします。

0ki 2019年01月16日

@ TD-erは書いた：

したがって、wifiをオフにして、最初からやり直してください。また、これらの手順の間に待機して、バッファが空になるか、少なくともフラッシュされ、未処理の要求がアクティブにキャンセルされていることを確認します。

フラッシュについてはよくわかりません... client.stop()前にすべてのclient.flush()呼び出しを削除したので、切断の頻度も少ないようです。いくつかのドキュメントを読んでいると、フラッシュによってすべての（tcp）入力バッファーが削除されることがわかりました。理論的には、応答が失われる可能性があります...

clumsy-stefan 2019年01月16日

2cを追加するだけで、いくつかのMikrotik APがあり、いくつかのsonoffがespurnaを実行し、いくつかのNodeMCUがESPEasyを実行しています。バックアップなどのネットワークのトラフィックが多い期間中にESPデバイスを失うため、ESPデバイス用にAPを追加する必要がありました。これはWiFiの信号強度とトラフィックに関連していると思います。追加のAPが追加された後、この問題が再び発生したことを覚えていません。

しかし、私のNodeMCUとESPEasyデバイスにはいくつかの切断があります。デバイスにnetdatapingモニターをセットアップし、これがいつ、どのように、なぜ発生するのかを把握し、情報を返すかどうかを確認します。

LeeNX 2019年01月17日

別の注意点として、@ clumsy-stefanのような40以上のデバイスはなく、約5人のユーザーとそのモバイルデバイス、およびTVのような奇妙なスマートデバイスしかありませんが、Mikrotikデバイスが過負荷であるか、WiFiRFネットワークが飽和している可能性があります？

RFノイズの量を確認する方法があればいいのにと思います。 APの数とそれらがWiFiチャネルをどのように拡散するかを表示するアプリ（WiFiアナライザー）があります。このツールを使用して、さまざまなWiFiAPのWiFiチャネルを設定しました。

しかし、他のRF干渉があるかどうかは実際にはわかりません。

オーバーロードされたMikrotikデバイスのアイデアについては、メインルーターにMikroTik 951UI-2HNDを使用し、ESPAPとしてMikroTikRB9412nD hAPliteを使用しています。

その情報はなんらかの形で役立つのだろうか？

LeeNX 2019年01月17日

@LeeNXヒントをありがとう。私のノードは3つのAPに分散されており、RFはある程度バランスが取れている（APあたり最大20クライアント程度）ので、干渉はできるだけ少なくなります（もちろん、干渉がないことはありません...）。したがって、MTが過負荷になることはないと思います（私はプロのイベントなどにネットワークバックボーン接続とWLANを提供する会社で働いているので、インフラストラクチャの詳細なテストをかなり行っています）が、過負荷の通信時間は可能性があることに同意します問題になる可能性があります...ただし、たとえそうだとしても、ノードは切断後に250回を超えて再接続できず、再起動するとすぐに再接続します。通信時間の問題にはなり得ないと思います...私以外は他のデバイスでそれを確認してください...
したがって、内部Wi-Fiチップの状態、Wi-Fiコアが取得するCPU時間の量、およびESPEasy部分で実行されている他のタスクの間の偶然または競合状態であると私はまだ考えています...

clumsy-stefan 2019年01月17日

@ clumsy-stefan私はあなたの洞察に同意します。 40以上のノードを備えた小さなMikrotikAPを使用すると、MikrotikのCPUまたはRAMが制限される可能性があることを指摘したかったのですが、それは問題ではないようです。

ESP CPUと他のプラグインの影響をテストできないように、ESP32とNodeMCUデバイスをベースのESPEasyコア以外のものと一緒に展開して実行するかどうか疑問に思っています。展開できるものとnetdatapingテストを参照してください。

これで役立つ情報が得られたら、報告します。

みんなありがとう！！！

LeeNX 2019年01月17日

ここにはほとんど何も実行されていないノード（IR RX / TX）があり、問題なく数週間実行されています。
稼働時間が40日を超えるもう一方のノードは、DomoticzMQTTとBME280 + MH-Z19CO2を実行しています。
したがって、実行中のプラグインとその頻度、および読み取り間隔が常に他のプラグインの読み取り間隔と一致するかどうかにも依存します。

スケジューラーで初期オフセットを使用して、いくつかの定期的な関数呼び出し（10 /秒、1 /秒、および30秒）を既に設定しているため、さまざまなループ呼び出しで可能な限り実行され続けます。

Taskerのように割り込みタイマー駆動のイベントを追加して（または、作成したスケジューラーの代わりにtaskerを使用して）、delay（0）を実行するために1つのタスクを10ミリ秒間隔で設定する必要があるかもしれません。
唯一のことは、他のGPIO転送を中断し、センサーの読み取りを妨げる可能性があるということです。

TD-er 2019年01月17日

それはおそらく4way-HSの問題を解決するでしょうが、再接続の問題ではないと思います...それはまだ最も奇妙な問題です...私はテストノードが12時間再び失敗し、APに300回以上再接続しようとしました成功。それを（ソフト）再起動した後、それは即座に再接続しました（再起動+再接続には約5秒かかりました）...

clumsy-stefan 2019年01月17日

私はちょうど私たちがここで見ているものに非常に関連しているように見えるこの問題を見つけました：
https://github.com/esp8266/Arduino/issues/5527

TD-er 2019年01月17日

似ているように見えます、はい...しかし、wifiをオフに呼び出しても変更されないようです（試してみました）。現在、ここで提案されているように、 WiFi.begin()を呼び出す前にWiFi.setOutputPower(0)試しています
https://github.com/esp8266/Arduino/issues/2235
そしてここ
https://github.com/esp8266/Arduino/issues/2186#issuecomment -233853152
まだそれが起こるのを待っています。

clumsy-stefan 2019年01月17日

似ていますが、同じではありません。実際、私たちの場合、APを再起動しても問題は解決しますが、Gijsによって投稿された問題では、APを再起動しても問題は解決しません。

giig1967g 2019年01月17日

@ giig1967g APを再起動しても解決しません！ノードを再起動するだけで、ノードは再接続されます（私の環境では）...

clumsy-stefan 2019年01月17日

@ giig1967g @ clumsy- https ：

ですから、ここにはいくつかの問題があるようです。

TD-er 2019年01月17日

@ clumsy-stefan
ああ、わかりました。そして私の場合はMikrotikだけで... :(
@ TD-er
多分あなたは彼らが使用しているAPブランド/モデルを尋ねるべきです...

giig1967g 2019年01月17日

@ giig1967gここにも到達できないノードがいくつかありましたが、それらのイベントの間隔は10日をはるかに超えていたため、これらの問題の1つに関連しているかどうかを判断するのは少し難しいです。
私のノードの約半分はMikrotikに接続され、残りの半分はFritzbox1750Eに接続されています

TD-er 2019年01月17日

@ giig1967g私もMTしか持っていません...そしてそれは信号が弱いノードとGPIOが使用されているノード（特にPCF）でより頻繁に発生するようです...

clumsy-stefan 2019年01月17日

RFノイズの量を確認する方法があればいいのにと思います。 APの数とそれらがWiFiチャネルをどのように拡散するかを表示するアプリ（WiFiアナライザー）があります。このツールを使用して、さまざまなWiFiAPのWiFiチャネルを設定しました。
しかし、他のRF干渉があるかどうかは実際にはわかりません。

mikrotikで/interface wireless registration-table print interval=1して、SNRを確認できます。

0ki 2019年01月17日

残念ながら、 WiFi.setOutputPower(0)も役に立ちません

これは、「グループキーの更新タイムアウト」または「4wayハンドシェイクが失敗した」後にのみ発生するようです。ノードを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

clumsy-stefan 2019年01月17日

簡単な説明： wifi_set_phy_mode(PHY_MODE_11G);を追加し、ノードを802.11gモードに強制することは、少なくとも回避策のようです。数時間以来、どのユニットも再起動していません。また、上記のグループキータイムアウトの問題からユニットが1〜2回回復しました...
おそらくに関連している

•ESP8266SoftAPは802.11b / gのみをサポートします。

これはドキュメントに記載されています...

安定していれば、後で/明日更新します...

clumsy-stefan 2019年01月19日

👍1

他の誰かがすでに（数回）指摘しているように、802.11Gに切り替えることで感度も上げる必要があります。
それに対する私の目的は、ほとんどのAPがN、G、Bを切り替えるときに問題が発生することです（だったのですか？）。
混合クライアントがありますか？（GとN）同じAPでアクティブですか？

TD-er 2019年01月19日

私はすべてのMikrotikで異なるモードを使用しています。 B / G / N / ACが混在し、仮想APを含む2 / 5GHzの両方の帯域が定義されています...異なるクライアントが同じAP上の異なるモードに問題なく接続します（esp8266を除く）。

clumsy-stefan 2019年01月19日

良いニュース（少なくとも私にとっては）...私のノードは、切断/再起動/フリーズせずに過去12時間実行されました！

ノードを802.11gに強制すると、MikroTikAPとスムーズに連携するようです。少なくともこれは簡単な回避策です（802.11nの追加速度が必要ない限り）。

誰かが自分自身をテストしたい場合は、関数tryConnectWiFi()の行644の周りに次の行（ setupStaticIPconfig(); ）にESPEasyWifi.ino追加するだけです。
WiFi.setPhyMode(WIFI_PHY_MODE_11G);

SoftAPモードが802.11nをサポートしておらず、ノードがNモードで接続されているため、問題が発生すると推測できます。コアはどういうわけか「混乱」します...しかし、これはコア担当者に発生する問題だと思います。 ..

ESPEasyの場合、これを構成可能にすることができます（@ TD-er？）。これにより、構成ページでESPを実行するモード（B / G / N）を選択できます。

clumsy-stefan 2019年01月20日

👍1

はい、詳細設定に選択オプションを追加します。
誰が最初にそれを尋ねたかを忘れましたが、それを調べて、コミットで彼も信用します;）

TD-er 2019年01月20日

完璧！クレジットは必要ありません。機能するために必要なだけです;）だから、彼にそれを捧げてください！ 😄

デバッグ中に、変更することをお勧めする他の小さなものをいくつか見つけました（プラグイン呼び出し後に無条件にdelay()呼び出す、いくつかの追加の{} 、およびログ出力へのいくつかの追加など。これらのASPITまたはそれをそのままにしておきたいですか（これらは重要な変更ではなく、おそらくいくつかのマイナーな改善であると思います）？

clumsy-stefan 2019年01月20日

PRしてください。
それは少なくとも議論を助け、あなたの発見を追跡するでしょう。
また、チェックした内容にコメントを追加すると便利です

TD-er 2019年01月20日

参考までに＃2012
開発者へのすべてのクレジット。チーム！

Domosapiens 2019年01月20日

このパッチにはWiFi.setOutputPower（0）のアイデアも含まれていますか？

私は今7日間実験を行っています。
mega-20180224ノード-ゼロリブート
mega-20190110ノード-35回の再起動。今日はそのうちの9つ。

0ki 2019年01月20日

コードに関連する行を残しましたが、コメントアウトしました。したがって、 ESPEasyWiFi.inoの//（約644行目）を削除して再コンパイルする必要があります。

clumsy-stefan 2019年01月20日

@oki申し訳ありませんが、あなたの質問を間違って読んだのを見ました...再接続する前に電源を0に設定しても違いが見られなかったので、これは含まれていません...それで私はそれをもう一度破棄しました！

clumsy-stefan 2019年01月20日

私は今7日間実験を行っています。
mega-20180224ノード-ゼロリブート
mega-20190110ノード-35回の再起動。今日はそのうちの9つ。

それは効果的に比較しています：

イベントベースのwifiなしのコア2.3.0
イベントベースのwifiを備えたコア2.4.2。

TD-er 2019年01月20日

良いニュース（少なくとも私にとっては）...私のノードは、切断/再起動/フリーズせずに過去12時間実行されました！
ノードを802.11gに強制すると、MikroTikAPとスムーズに連携するようです。少なくともこれは簡単な回避策です（802.11nの追加速度が必要ない限り）。

私はテストのためにそれを逆にしました。
MikrotikをNモードのみに設定しました...すべてのESPは、1回の再起動なしで12時間以上実行されています。

chunter1 2019年01月21日

良い有効なアプローチも！残念ながら、N機能のないクライアントを多数実行しているため、これを実行することはできません...

clumsy-stefan 2019年01月21日

Bモードを無効にし、G / Nのみを有効にするだけです。 Bモードがない方がいいです。 Bモードとレートのみをサポートする10年前の古い電話または（通常）wifiバーコードスキャナーをお持ちでない限り。

Bモードでのアンテナの追加感度も、範囲内で重要な役割を果たしません。 Bモードは放送時間を食い尽くします。 Bモードを使用しないことには文字通り欠点はなく、GよりもNモードを使用することにも欠点はありません。 Nモードの範囲はBやGよりもさらに優れています。

jimmys01 2019年01月21日

@ jimmys01そうです、Bモードはおそらくもうどこでも使用されていません...しかし、Nだけに行くことはできません...したがって、ノードが安定している場合、G / Nモードで何が起こるかをテストする必要があります4wayHSタイムアウトの場合に再接続できます。

clumsy-stefan 2019年01月21日

g / nは私にとって不安定です。

0ki 2019年01月21日

これは、esp8266がモード（B / G / N）間を移行するたびに問題が発生することを意味しますか？

chunter1 2019年01月21日

これは、esp8266がモード（B / G / N）間を移行するたびに問題が発生することを意味しますか？

可能性が非常に高い。
Gモードのみをサポートする一部のデバイス（ESPデバイスではない）で多くの問題が発生しました。
N個のデバイスと組み合わせて使用すると、到達できないように見える場合があります。
悪名高いのは、HomeWizardといくつかのWiFiカムです。

TD-er 2019年01月21日

この新しいバージョンmega-20190121では、ESPはより安定しているようで、今までクラッシュ/ WLANの問題はありませんでした。
しかし、今ではOLED（framedPlugin）をオフにすることはできません。 OLEDFRAMEDCMDをオフにすると、ディスプレイが非常に短時間オフになり、その後再びオンになります。
古いバージョン（2018年から）で連続テストを行ったところ、ディスプレイは期待どおりに反応しました。

kischde 2019年01月23日

mega-20190121を試してみましたが、WiFiの安定性は同じです。起動から約1時間以内にクラッシュします。

@ TD-er、私がテストできるように、議論された変更を含むバージョンをいつプッシュできると思いますか？

0ki 2019年01月23日

クイックアップデート：モード修正を802.11gに設定してから、フリーズや再起動などがなくなりました。 APは混合g / nモードで動作しますが、wifiモードをespで構成できるようにするパッチにも投票します。

clumsy-stefan 2019年01月23日

すぐにパッチを期待してください😉

chunter1 2019年01月23日

B / Gのみを選択するためのコミットを追加しました。
ESP32ではまだうまく機能していないので、ESP32用に選択するオプションを無効にしました。
また、APがB / Gのみを許可していない場合に再度接続できるように、フォールバックオプションを追加しました。

TD-er 2019年01月24日

@ TD-er私はこの変更を意味します：

私の推測では、コアライブラリ（LWIPまたはArduinoまたはESP）に問題があり、wifiをリセットする必要があります。
したがって、wifiをオフにして、最初からやり直してください。また、これらの手順の間に待機して、バッファが空になるか、少なくともフラッシュされ、未処理の要求がアクティブにキャンセルされていることを確認します。

最後の2つの投稿で議論された変更？
まだ実装されていませんが、今夜、コーディングしてテストビルドを作成することができます。

0ki 2019年01月24日

@oki両方のバリエーションを試し、出力電力を0に設定し、問題が発生したときにアクティブに切断/再接続しました。どちらのバージョンもAPのリセット/再接続に役立ちませんでした...（私の環境では）...上記の詳細...
それを安定させた唯一のことは、Nモードを使用することでした。

clumsy-stefan 2019年01月24日

私はそれをよく知っています。すぐにパッチを期待しているので、デバッグを続けることができます。

0ki 2019年01月24日

@ 0kiこの最新のコミットを使用してテストビルドを作成できます。
それとも、WiFiを無効にしてテストしたいですか？

もしそうなら、あなたはどのようなオプションが欲しい/必要ですか？ WiFiをオフ/オンにして、すべてのサービスを再起動しますか？
その最後の部分（サービスの再起動）も、ソケットを使用するすべてのサービスが適切に再起動されるかどうか完全にはわからないため、よく見る必要があります。
それはまた、WiFi接続が再作成されるときに私が推測するいくつかの問題を引き起こす可能性があります。

TD-er 2019年01月24日

切断が検出されると、wifi送信機を自動的に完全にオフ（そしてオン）にします。

0ki 2019年01月24日

コードを追加したようです。これをテストするためにどのバージョンをプルできますか？

0ki 2019年02月01日

よくわかりませんが、テスト用に新しいビルドを作成します。
+/- 30分で完了します。

TD-er 2019年02月01日

テストビルド
これは、今日以前にマージしたものと、B / Gモードで接続するための変更が加えられたPR＃2235に基づいています。
そのPRのいくつかのプラグインに問題があるように思われるので、それがまだマージされていない理由です。

TD-er 2019年02月01日

ありがとう！テストビルドをフラッシュしました。

現在、次の設定があります。
Connection Failure Threshold: 0 Force WiFi B/G: NO Restart WiFi on lost conn.: YES

PLATFORMIO_ESP12Eがあることを考慮して、別の方法でテストする必要があると思いますか？
つまり、b / gがesp12eで機能するかどうか、および接続障害のしきい値が正確にどのようなものであったかを忘れました。

0ki 2019年02月02日

このしきい値は、失敗した接続試行の数がその値を超えている場合に再起動を開始するための単なるカウンターです。
0がデフォルトであり、再起動を実行しないことを意味します。

50または100に設定すると、到達しにくい場所にあり、再接続ループに入ったときに再起動するのに役立つと思います。

この設定を使用しても、多くのノードがすでに表示しているように、HWウォッチドッグの再起動が表示される場合があります。
B / Gモードがアクティブな状態で再現するのは難しいかもしれません。

TD-er 2019年02月02日

テストビルド
これは、今日以前にマージしたものと、B / Gモードで接続するための変更が加えられたPR＃2235に基づいています。
そのPRのいくつかのプラグインに問題があるように思われるので、それがまだマージされていない理由です。

テストビルドをありがとう。
以前は最も不安定だったESP12Fが、再起動せずに59時間稼働しています:)

編集：設定は次のとおりです。
強制WiFiB / G：はい
失われた接続でWiFiを再起動します。：はい

chunter1 2019年02月04日

そのコミット（B / G WiFi）を別のPRに分割するので、マージを待機している残りのPRを修正する前にマージできると思います。

TD-er 2019年02月04日

👍3

良いアイデア！

以前の設定RestartWifi = YESは何も役に立ちませんでした。

今私はに切り替えました

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

再起動も1回も切断せずに、2日間稼働しています。すごい。このテストリリースから離れることすらできないと思います。

0ki 2019年02月04日

約後。 100時間、モジュラーは最終的にリセットを行いました。 :(

リセット理由：ハードウェアウォッチドッグ

ただし、これは難しい構成（12 x 1-wireセンサーとFHEMサーバー）が原因である可能性もあります。

chunter1 2019年02月06日

このパッチを追加することもできます： //github.com/letscontrolit/ESPEasy/pull/2235/commits/9a05eaf828a737ae416ab11c8df8c4a5b03ceaf2
多分それはまた安定性を改善するのを助けるでしょう。
このテストビルドに含まれ

TD-er 2019年02月06日

このパッチを追加することもできます： 9a05eaf
多分それはまた安定性を改善するのを助けるでしょう。
このテストビルドに含まれ

ありがとう！
完全に異なる2つの構成済みユニットにインストールし、フィードバックを提供します。

chunter1 2019年02月06日

を含む私のテストノードの1つで実行されました
https://github.com/letscontrolit/ESPEasy/commit/9a05eaf828a737ae416ab11c8df8c4a5b03ceaf残念ながら、group-key-timoutの問題が再び発生し、回復しないか、APに再接続するまで、約2時間しかかかりませんでした。「接続が失われたときにwifiを再起動する」が有効になっていて、B / Gに強制されていない場合、Nはまだ問題のようです。
したがって、私にとっては、B / Gモードが依然として唯一の安定した動作オプションです。

clumsy-stefan 2019年02月07日

Nサポートを完全に削除することを検討できますか？このような単純なデバイスに対して、Nが提供するメリットが必要ですか？

0ki 2019年02月08日

@ TD-erに組み込まれているB / Gモードを強制する「new」オプションを備えた

clumsy-stefan 2019年02月08日

これをメイン設定に移動するときは、このオプションをデフォルトでオンにして出荷することをお勧めします。

0ki 2019年02月08日

👍1

動的にすることができます。
接続できない場合は、Nオプションをオンにして再試行してください。

APでNのみがチェックされているセットアップはたくさんあります。したがって、これらの環境では、ESPeasyでNサポートを無効にしている場合は元に戻すことはできません。

TD-er 2019年02月08日

👎2

このパッチを追加することもできます： 9a05eaf
多分それはまた安定性を改善するのを助けるでしょう。
このテストビルドに含まれ
ありがとう！
完全に異なる2つの構成済みユニットにインストールし、フィードバックを提供します。

これまでのところ、1つのモジュラスは2日後に再起動し、もう1つは5日後に再起動しました。
どちらもリセット理由として「ハードウェアウォッチドッグ」を表示しました。
両方のモジュールが「WiFiB / Gを強制する：はい」および「失われた接続でWiFiを再起動する：はい」に設定されています。
APはB / Gのみに設定されたMikrotikです（稼働時間49日）。
APとモジュール間の距離は約。 2 ... 3メートル。

chunter1 2019年02月11日

なぜそれを動的にする（B / Gのみの設定からNに戻る）という私の提案が2つの賛成票を受け取ったのか疑問に思いました。
それが良い提案ではない理由を詳しく説明してください。

TD-er 2019年02月11日

なぜそれを動的にする（B / Gのみの設定からNに戻る）という私の提案が2つの賛成票を受け取ったのか疑問に思いました。
それが良い提案ではない理由を詳しく説明してください。

私の意見では、誰かがこのオプションをオンにした場合、彼はすでにより安定性を必死に探していて、これが彼のAP設定にとって何を意味するかを知っています。
B / Gのみのオプションを選択した場合、B / Gを使用していると思うが、使用しない状況になりたくないので、静的なソリューションを好みます。
ただし、ノードはとにかく再起動しているので（頻度ははるかに低いですが）、新しいコアに関連する問題の実際の解決策が欲しいです。

chunter1 2019年02月11日

わかりましたが、ユーザーが設定の機能を知らず、到達不能なノードになってしまう場合の問題も理解する必要があります。
したがって、Nサポートに戻る前に、大きなしきい値が必要です。
たとえば、破損したプラグインのフォールバックは次のとおりです。
再起動に10回失敗すると、1つのプラグインまたはコントローラーが無効になり、再起動が成功するかどうかが確認されます。

同様のことがwifi接続にも適用できます。
Xが再接続に失敗した後、802.11Nでの接続が許可されます
Gモードネットワークの方が受信品質が良いので、Xを10のようなものにすると、GではなくNに接続する可能性はほとんどありません。特にNモードで試行するたびにこのカウンターをリセットする場合はそうです。

TD-er 2019年02月11日

うーん、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にリセットされます。

これは許容できる解決策ですか？

TD-er 2019年02月11日

うーん、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のバグがすぐに見つかることを願っています）。

chunter1 2019年02月11日

B / Gの設定に関するフィードバックのみ。
最新の20分ごとに再起動する1つのユニットにテストfwをインストールしました。 -72dBiでNに接続される前。これは、切断しないのに十分な信号であるはずです。 -105dBiの受信機能を備えたエンタープライズグレードのAPを運用しています。したがって、チャネルをドロップすることはありません。

テストFWで数時間後、これまでのところリセットはありませんでした。
私はそれを実行し続け、報告します。

PS：私はそれがどういうわけかNに関連していることに同意します。
PSS：4Mにアップグレードされた20個のESP-07ノードを実行しています。時間はかかりますが、再フラッシュが必要な場合は返済します。

NorbertRoller 2019年02月11日

120以上のノードがすべてGN（mega-20190202）で実行されており、問題はありません。それらはすべてNに接続されていると報告しています

jimmys01 2019年02月11日

👍1

@ jimmys01同じAPに接続しているノードはいくつですか？
そして、そのAPのブランドは何ですか？（Mikrotik？）

TD-er 2019年02月11日

それらのほとんどすべてが異なるAPに接続します（ホテルの部屋ごとに1つ）スイッチ（PIRセンサー）、HTU温度および湿度センサー、およびIRLEDがあります。
APブランドはMikrotikです。
設定は次のとおりです。
国が設定されています
制御チャネル：20Mhz
バンド：GN
拡張チャネル：無効
認証タイプ：WPA2PSKのみ
暗号化：aesccmのみ
グループ暗号化：aes ccm
Groyp Key Update：00：01：00

jimmys01 2019年02月11日

B / Gの設定に関するフィードバックのみ。
最新の20分ごとに再起動する1つのユニットにテストfwをインストールしました。 -72dBiでNに接続される前。これは、切断しないのに十分な信号であるはずです。 -105dBiの受信機能を備えたエンタープライズグレードのAPを運用しています。したがって、チャネルをドロップすることはありません。
テストFWで数時間後、これまでのところリセットはありませんでした。
私はそれを実行し続け、報告します。
PS：私はそれがどういうわけかNに関連していることに同意します。
PSS：4Mにアップグレードされた20個のESP-07ノードを実行しています。時間はかかりますが、再フラッシュが必要な場合は返済します。

残念ながら、ユニットはランダムな時間の後もリセットを続けます。 1〜4時間以内のもの。
B / GのみFWは私の問題を解決しません

NorbertRoller 2019年02月12日

なぜそれを動的にする（B / Gのみの設定からNに戻る）という私の提案が2つの賛成票を受け取ったのか疑問に思いました。
それが良い提案ではない理由を詳しく説明してください。

外部/環境の状況により、wifi自体が1時間ダウンしたとします。私のノードはNに切り替わり、再び非常に不安定になります（私のアプリケーションは再起動に敏感です-wifiは常にそこにある必要はありませんが、ノード自体は常に動作している必要があります）。

不安定さを回避し、Nに接続することのないノードの構成が必要です。

0ki 2019年02月12日

これをメイン設定に移動するときは、このオプションをデフォルトでオンにして出荷することをお勧めします。

解決策として、これをデフォルトでフォールバックモード（B / G-then-N）に出荷し、B / GのみまたはB / G / Nに切り替えることができます。

2.5.0の実際のソリューションについては、次のことを試してください。

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

0ki 2019年02月12日

120以上のノードがすべてGN（mega-20190202）で実行されており、問題はありません。それらはすべてNに接続されていると報告しています

許容可能な時間枠内に120以上のノードをどのように更新しますか？
「..何の問題もありません...」各ノードの稼働時間を確認しましたか？それは何ですか？
最後に意図した再起動以降、すべて同じですか？

chunter1 2019年02月12日

稼働時間は日数をカウントし、それらすべての再接続は0です。 APでPMKIDを無効にした場合を除いて、数か月間、接続に問題が発生することはありませんでした。おそらく、新しいコアはWi-Fi設定についてよりうるさくなったか、私には何がわからないのでしょう。来月にはさらに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 2019年02月12日

@ jimmys01最近、自分で

そして、コア2.5.0ビルドに関する通知です。
今後のナイトリービルドでは、2.5.0ビルドは含まれていません。これは、コア2.5.0にバグがあり、Webサーバーが応答を停止し、ノードがクラッシュするためです。
それが修正されるとすぐに、コア2.5.0ビルドが再びあります。
前回のナイトリービルドには、コア2.6.0 alphaが含まれています。これは、基本的にコアライブラリのgithubからの最新のコードであるため、自分で確認できます。

TD-er 2019年02月12日

2つのモジュールで4日以降、B / Gのみが実行されている2.6.0を取得し、最初のモジュールで再起動しました。
リセットの理由は、通常の「ハードウェアウォッチドッグ」でした。
「B / G」のみのモードがアクティブであるために私が観察したのは、リセットが発生する前の3。5日の実行時間です。

chunter1 2019年02月19日

Wi-Fiの切断数も比較してみてください。これらの切断は、クラッシュに関連しているようです。

TD-er 2019年02月19日

両方のモジュールはセラーにあり、MikrotikAPからわずか2..3m離れています。
同じFWバージョンを実行している2番目のモジュールを確認したところ、再接続が0で、稼働時間が4d02hでした（フラッシュしてから再起動しません）。
私は、リセットを行った他のモジュールを大いに信じています。また、リセットする前に再接続が0回ありました。

2つのテストモジュールで構成されたタスクについて：
リセットしたモジュールには、120秒ごとに値をFHEMサーバーに送信する12個のDS18B20センサーが構成されています。
これまでリセットされなかったモジュールには、2つのgpiosのみが構成されており、120秒ごとに同じFHEMサーバーに値を送信します。

したがって、AP（Mikrotik）は同じ、距離（2..3mm）は同じ、FHEMサーバーは同じです。12個の温度センサーを備えたモジュールだけが、2個のgpiosを備えたモジュールよりも確実に頻繁にリセットされます。

chunter1 2019年02月19日

私のノードでは、これは主に、fhemが応答するのが遅すぎるか、最大再試行を100に定義したために到達できない場合に発生し、ノードが再起動します（手動での再起動も表示されます）。

clumsy-stefan 2019年02月19日

私のノードでは、これは主に、fhemが応答するのが遅すぎるか、最大再試行を100に定義したために到達できない場合に発生し、ノードが再起動します（手動での再起動も表示されます）。

再試行回数が100回を超えると、ノードを再起動する必要があるのはなぜですか？
（テストのために再試行を0に設定しました）

chunter1 2019年02月19日

ツール->詳細->接続障害のしきい値

モジュールのwifiが何らかの理由でチョークした場合、しばらくすると再起動することを確認します...

clumsy-stefan 2019年02月19日

「再試行」とは、FHEMのコントローラー設定の「最大再試行：」ではなく「接続障害しきい値：」を意味します。
接続障害のしきい値を0に設定しました。

chunter1 2019年02月19日

👍1

ところで：「B / Gのみ」がアクティブであったにもかかわらず、初めて4WHSタイムアウトの問題でスタックしたノードがありました...これまでにそれはありませんでした（自己コンパイル、2.5.0コア）...これが偶然だったら、私はこれを見続けます...

clumsy-stefan 2019年02月19日

SDK3.0.0には多くの問題があるため、使用済みのSDKをSDK2.2.1に戻すコア2.5.1がまもなく登場することに注意してください。
これにより、ノードがWi-Fiでどのように反応するかも変更され、コア2.4.2に再び匹敵する可能性があります。
コア2.5.0にどのような修正が含まれているかわからないため、直面している他の問題が修正される可能性があります。

@ chunter1あなたが持っているノードについて。
再起動したものはコントローラーに多くのメッセージを送信していたようです。したがって、統計的に言えば、プロセスのどこかで停止したものを送信しようとする可能性が高くなります。

TD-er 2019年02月19日

@ clumsy-stefan Githubで現在のコードをテストできますか？（または最新のビルド）

ネットワーク関連のアクティビティの実行方法にいくつか変更を加えました。

TD-er 2019年02月27日

これですか？

ESP_Easy_mega-20190227_test_core_260_sdk3_alpha_ESP8266_4M.bin

chunter1 2019年02月27日

昨夜のほぼすべてのビルド。
また、SDK2を使用してコア2.6.0の「通常の」バージョンを追加しました。
Core 2.6.0 SDK2は現在、いくつかのノードで実行されており、そのうちの1つにHWウォッチドッグしかなく、リソースが非常に少なく（大量の高メモリプラグインを実行している）、フラッシュメモリが使い果たされている可能性があります（何千ものファームウェアアップデートがあったので、それを捨ててください）

TD-er 2019年02月27日

@ TD-er約6時間前にgitからコンパイルして2つのテストノードにインストールしました。しかし、インターネットアクセスがまだ非常に限られているため、おそらく24時間以内にしかレポートできません。

clumsy-stefan 2019年02月27日

👍1

Mikrotikルーターで「ForceB / Gモード」を使用して最新のファームウェアをテストしてきましたが、これまでのところ安定して動作しているようです。報告します。

@ TD-er 1つの質問：「強制B / Gモード」が設定されている場合のNモードへのフォールバックのルールは何ですか？

giig1967g 2019年03月08日

@ giig1967g
_B / Gのみ_でAPに10回以上接続できなかった場合、デフォルトのBGNモードに戻ります。

したがって、APがしばらくオフラインだった場合、Nモードで接続する可能性が残ります。
これが実際の問題であると思われる場合は、10回ごとにのみ実行するように設定できますが、フォールバックssidが試行されたときにもそれが試行されることを確認する必要があります。

TD-er 2019年03月08日

こんにちは@ TD-er
フォールバックは悪い考えだと思います。
このシナリオを見てください。MikrotikでユニットをB / Gモードに強制的に実行しています。
何らかの理由で私のMikrotikがオフラインになります（更新、再起動など）。
mikrotikが再び起動するたびに、ESPはNモードで接続され、ユニットの安定性が失われます。

つまり、Force B / Gモードを設定して接続が失敗した場合、AP（192.168.4.1）になるはずですが、Nモードにフォールバックするべきではありません。フォールバックの可能性は、ユーザーに誤った期待を生み出します。

誤解しないでください。フォールバックは変更の有効性をテストするのに適していましたが、問題が解決することが証明されたので（少なくともこれまでのところ）フォールバックを削除する必要があります。

@ chunter1のコメントに同意します： //github.com/letscontrolit/ESPEasy/issues/1987#issuecomment -462295204

giig1967g 2019年03月08日

では、次のシナリオについてどう思いますか。
B / Gのみを使用して特定のAPに接続できるようになるとすぐに、フォールバックを提供しないように追加のフラグが設定されます。
これらの設定の一部（B / Gのみ、または他のAP設定）が変更された場合、特定のAPへの接続が成功するまで、フォールバックが再度有効になります。

編集：
フォールバックとは、「フォールバックSSID」ではなく、これらの追加設定を意味します

TD-er 2019年03月08日

つまり、フォールバックはAPへの最初の接続が成功するまでアクティブのままであり、その後削除されます。この場合、syspageでwifiモードを確認すると便利です。
Force B / Gを設定した場合、Nへのフォールバックを回避したい場合でも、これは可能な解決策です。
ユーザーが間違いを犯す可能性があることは理解していますが、ユーザーがSSIDを間違って入力し、どのような場合でもユニットにアクセスできない可能性があります...

別の質問：現在の実装では、ユニットはどのシナリオでAPになりますか？
ユニットはB / Gを10回試し、次にNを試すように思えますが、最終的にはあきらめてAPになりますか？

giig1967g 2019年03月08日

いいえ、指定されたAPに接続するためのテストを行っている間、APモードはアクティブなままです。
おそらく、稼働時間のオプションのチェックを追加し、ノードが起動された最初の10分間にのみAPモードの開始を許可する必要があります。
セキュリティを強化し、APモードがESPに影響を与えて特定のwifiネットワークに到達できない可能性を排除するためです。

そして、私たちはプロジェクトの「簡単な」部分に焦点を合わせ続ける必要があります。
これは、適切なデフォルトが提供され、圧倒的な量の設定が提供されないことを意味しますが、専門家にすべてを行うオプションを提供します。
これは、経験の浅いユーザーには適切なフォールバックが必要であることも意味します。
特にB / Gのみの設定の場合。 ESPeasyを始めた人の90％以上が、802.11B / G / Nの違いを認識していないと思います。したがって、フォールバックを使用して非常にうまく処理できる問題が発生した場合、他のプロジェクトを探す可能性があります。。
また、このフォールバックが「安定性」の誤った感覚を与えてはならない理由も理解しているので、現在の実装に改善の余地がある理由を本当に理解しています。ただし、「最初の接続試行の成功=>フォールバックの無効化」が自動化されている場合は、経験豊富なユーザーにも最適です。（私が経験から知っているように、誰も愚かな間違いを犯します;））

どの接続設定が積極的に使用されているかをより明確にする必要があることに同意します。

TD-er 2019年03月08日

理解した。
したがって、プロサルは次のとおりです。
ユニットが起動します。
Nフォールバックフラグがtrueに設定されます。
FORCE B / Gが設定されている場合、B / GのwifiAPへの接続を10回試行します。
接続できる場合は、Nフォールバックフラックをfalseに設定します。
接続できない場合は、Nモードで試行します。

Force B / Gが設定されているこのシナリオも考慮してください：電源障害。
ESPとWifiルーターの電源がオフになっています。
その後、電力が戻り、ESPはwifiルーターよりも速く起動します。
この場合、10回経過してもwifiAPがまだリッスンしていない可能性があります。
したがって、ユニットはNモードを試し、最終的には成功します。
（経験豊富な）ユーザーは、接続がNモードであったことを知らず、安定性に欠けるB / Gモードであると考えます。

主張したくはありませんが、実際にはこのハードウェアとフリーズの問題は1年前から続いています。コミュニティの助けを借りて1つの実用的な解決策を見つけたので、それが適用されたままであることを確認することを強くお勧めします。経験の浅いユーザーが「強制B / Gモード」を設定するリスクは、間違ったSSIDを設定するよりも少なく、同じ結果になります。つまり、アクセスポイントにアクセスできません。

提案：
経験の浅いユーザーが間違えないようにするために、「B / Gモードのテスト」にボタンを追加してみませんか。成功した場合は「FORCEB / Gモード」を有効にし、成功しなかった場合は無効のままにします。

この場合、経験の浅いユーザーは自分が何をしているのかを理解し、経験の豊富なユーザーはForceB / Gモードが設定されているときにNにフォールバックできないことを確信します。

どう思いますか？

あなたは出来る

giig1967g 2019年03月08日

起動した場合だけでなく、フォールバックオプションが設定で無効になり、保存されます。

TD-er 2019年03月08日

OK。その場合、自動チェックの代わりに手動チェックがさらに適切です。思いませんか？

giig1967g 2019年03月08日

はい、最初に簡単なチェックマークを追加してオーバーライドを無効にします。
しかし、後で私たち、「専門家」がミスを減らすのを助けるために、これをより動的にする必要があります:)

TD-er 2019年03月08日

OK

giig1967g 2019年03月08日

バージョン2019_02_16は、再起動せずに9日間実行されていました（強制的にB / G）。昨日、それは再び再起動し始めました。ハードウェアウォッチドッグはこれを2回強制しました。
しばらくすると、ユニットは到達できなくなりました。 WLANルーターの切り替えは役に立ちませんでした（3回、最大30分試行しました）。電源ヒューズを切り替えてESPを再起動しても効果はありませんでした。
再度WLANをシャットダウンし、192.168.4.1経由でESPに直接接続してアクセスする必要がありました。

何が起こったのか全くわかりません

kischde 2019年03月10日

@kischdeどのようなアクセスポイントを使用していますか？
昨夜、新しいAPのインストールを試しているときに、自分と同じようなことを経験しました。
MikroTik APをインストールしようとしましたが、ESPが再接続する必要があるまで、すべて正常に機能していました。
MikroTikのWebインターフェースを介して、ノードがWiFiに接続されていることがわかりましたが、IPアドレスを受信しませんでした。
電話のホットスポットに接続しようとしても、ESPを再起動できましたが、この動作が繰り返されました。
メインAP設定を別のAPに設定した場合にのみ、正常に接続が開始されました。

これを実現するためにノードが再起動されなかったことに注意してください。

私が持っている別のMikroTikと比較して、そのAPで「正しくない」に設定されていることの1つは、「距離」設定が「屋内」に設定されていることです。
ここで何が違うのかを確認するためにさらにテストを実行しますが、前に説明したように、パケットの応答のタイムアウト設定のようです。
また、ESPがDHCP要求に応答するのに時間がかかることも想像できますが、これはこの設定には短すぎる可能性があります。

TD-er 2019年03月10日

私はSwisscomAP（スイステレコムプロバイダーAP）を使用していますが、MikroTikを使用している人のように、さまざまな場所で同じ問題がすべてここに書かれていました。そのため、同じチップセットを使用している可能性がありますが、拡張設定など、設定を大幅に変更することはできません。
電源を再投入する前に、私もあなたと同じように、あなたと同じ動作で携帯電話に接続しようとしました。
DHCPを使用せずに修正IPを使用します
私は今実際の2019_03_05に切り替えました、何が起こるかを見るでしょう...

kischde 2019年03月10日

最近WiFi設定を変更しましたか？
たとえば、MACアドレスがBB：BB：BB：BB：BB：BBであるSSIDの別のAPの位置1にあるMACアドレスAA：AA：AA：AA：AAのアクセスポイント
ESPのどこかに保存されていない設定が残っているような気がします。

また、NonOSのドキュメントで、WiFi設定を変更したときにこれらを効果的にクリアする方法を確認します。
また、私のテストでは、2つ以上のSSIDを使用することが非常に役立つようです。
また、このためのフィールドをさらに追加するか、暗号化されたファイルをSPIFFSに保存して、ほぼ無制限の量のWiFiAPを保存できるようにします。

TD-er 2019年03月10日

最近WiFi設定を変更しましたか？

いいえ、APが1つしかないため、これはIMOでした。

kischde 2019年03月10日

OK。知っておくと良い。
何が原因なのかまだわからないので、できるだけ多くの未知数を排除しようとしています。
したがって、それを再び機能させるためにあなたがする必要がある唯一のことは、wifiの設定を再び追加することです。

TD-er 2019年03月10日

いいえ、さらに少ない
192.168.4.1経由でespに直接接続することを強制しました（APを無効にしました）
すべてをチェックしたが、異常なことは何も見つかりませんでした...そこで、ESPをリセットして再度実行するよりも、APを再起動してみます。そのため、IMOは「通常/その他」のWLAN接続を強制する必要がありました。
ところで、私はそれがAPで接続されているのを見ましたが、IPアドレスも割り当てられていませんが、静的です

kischde 2019年03月10日

うーん、私はそれで少し遊んでいます、私が遊んでいるMikroTikに接続された5つのノードで。

「Hw.FragmentationThreshold」を設定すると（オプションを「展開」するだけ）、ESPノードはIPアドレスを受信できなくなります。
この設定のデフォルト値は256です。1600に設定すると（完全なMTUに適合します）、すべてのノードがIPアドレスを受け取り、引き続き機能します。

これは、ノードが通信できるときにMikroTikUIに表示されます。

そしてこれは、データを送受信できない場合（ただし、WiFiレイヤーに接続されている場合）です。

TD-er 2019年03月10日

@ TD-er新しいesp8266コアにLWIP_FEATURESというオプションがあり、IP再アセンブリがアクティブになると思います...おそらくそれはビルドで定義されていませんか？

こちらをご覧ください： //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

clumsy-stefan 2019年03月10日

うーん、デフォルトが何であるかわからない。
Doxygenドキュメントの最初の行に記載されている番号はデフォルトですか？

TD-er 2019年03月10日

わかりません...プラットフォーム定義ファイルのArduinoIDEで、それを含めて定義するかどうかを選択できることを知っています。

clumsy-stefan 2019年03月10日

LWIPパーツは、コアディストリビューションにプリコンパイルされたライブラリとして含まれているといつも思っていました。
したがって、正しいフラグを使用してLWIPが再構築されていることを確認するのは非常に困難です。

TD-er 2019年03月11日

はい。ただし、リンク先（boards.txtから）によって異なります。

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

clumsy-stefan 2019年03月11日

したがって、彼らはこれらのフラグを使用しています：

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 |
| v2IPv6下位メモリ| -llwip6-536-feat | -DLWIP_OPEN_SRC -DTCP_MSS = 536 -DLWIP_FEATURES = 1 -DLWIP_IPV6 = 1 |
| v2IPv6高帯域幅| -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あります

TD-er 2019年03月11日

はい。ただし、 -lステートメントを見ると、最後に-feat付いたライブラリを使用する必要があります（ラベルとは対照的に、少し直感的です）...

clumsy-stefan 2019年03月11日

Espeasy: [バグ] [WiFiの安定性]レイヤー2が切断されたときのESP例外3/29

問題/機能要求の要約

予想される行動

実際の動作

再現する手順

システム構成

ルールまたはログデータ

最も参考になるコメント

全てのコメント195件

関連する問題