Espeasy: [BUG] [استقرار WiFi] استثناء ESP 3/29 عند فصل الطبقة 2

يبدو أن لدي نفس المشكلة. في بعض الأحيان ، فقدت شبكة wifi الخاصة بي الاتصال بشبكة wifi وتحافظ على "فقدها" من شبكة wifi لساعات. أعتقد أنه يجب عليهم إعادة التشغيل وإعادة الاتصال بشبكة wifi بفضل الوكالة الدولية للطاقة لكنهم لا يفعلون ذلك. التمهيد البارد يحل المشكلة.

هذا الشيء الأخير الذي وصفه wolverinevn هو شيء رأيته يحدث هنا أيضًا.

كما ناقشنا في # 1957 ، أنا متأكد تمامًا من أن الكثير من مشكلات WiFi / الشبكات الغريبة تأتي من عدم استقرار الطبقة 2 ... لقد رأيت كل أنواع السلوك الغريب قبل تغيير AP الخاص بي إلى بعض التوقيتات المتزايدة ...

كما ناقشنا في # 1957 ، أنا متأكد تمامًا من أن الكثير من مشكلات WiFi / الشبكات الغريبة تأتي من عدم استقرار الطبقة 2 ... لقد رأيت كل أنواع السلوك الغريب قبل تغيير AP الخاص بي إلى بعض التوقيتات المتزايدة ...

أتمنى أن تجد الحل. أحد Nodemcu الخاص بي يتوقف ويختفي من جهاز التوجيه لمدة 5 ساعات حتى الآن دون سبب. آمل أن تتعافى من هيئة الرقابة ولكن لا يحدث شيء. لا بد لي من إعادة تشغيله يدويًا الآن. منزعج للغاية!

wolverinevn عندما يكون لديك وصول إلى العقدة مرة أخرى ، انتقل إلى الأدوات =>

سيكون الحل الآخر إذا كان بإمكانك تعديل بعض المعلمات في نقطة الوصول الخاصة بك ، اعتمادًا في الواقع على نوع AP لديك إذا كان من الممكن تعديل ذلك ...

@ clumsy-stefan هل يجب أن نضع الإعداد الافتراضي في ESPeasy على هذا المستوى أيضًا؟

وربما يجب علينا أيضًا عرض هذه القيمة في صفحة sysinfo وإتاحتها للقواعد؟

@ TD-er إعداده على مستوى ما افتراضيًا ربما لا يكون شيئًا سيئًا إذا لم يكن منخفضًا جدًا (يمكن أن يحدث دائمًا فشل الاتصال).

عند تصحيح المشكلة ، فكرت في كيفية إجراء ذلك ، في الوقت الحالي ، يؤدي كل اتصال غير مفيد إلى زيادة العداد ويقلل الاتصال الناجح من أي وقت مضى. فكرت فيما إذا كان من المنطقي إعادة تعيينه إلى 0 بمجرد حدوث اتصال ناجح ، لكن أعتقد أن هذا سؤال أيديولوجي قليلاً ما هو أكثر منطقية.

المشكلة في هذا الرقم هي ، إذا كان لديك 10 مهام ، كل منها مع عدد إعادة المحاولة 10 وتأخير إعادة الإرسال 100 مللي ثانية ، فإن عمليات إعادة التشغيل تحدث بسرعة كبيرة إذا كانت هناك مشكلة اتصال حقيقية (100 إعادة محاولة في غضون 10 ثوانٍ تقريبًا.) .

الآن إذا كان لديك على سبيل المثال دائمًا 5 اتصالات فاشلة وواحدة ناجحة ، فستزيد باستمرار حالات فشل الاتصال. إذا حدث هذا طوال الوقت ، فستعيد تشغيل العقدة عاجلاً أم آجلاً على الرغم من إمكانية تسليم جميع البيانات.

المشكلة الرئيسية التي أراها هي أن العقدة بطريقة ما لا تدرك أن الاتصال على الطبقة 2 قد اختفى بالفعل ويستمر في إرسال البيانات (أعتقد). إلى جانب هذا ما أدركته الليلة ، ماذا يحدث لسجل النظام (والاتصالات الأخرى مثل NTP وما إلى ذلك) إذا لم يكن هناك اتصال wifi؟ هل هذا توقف ايضا؟ قد يفسر هذا سبب قفز العقد الخاصة بي فجأة إلى وحدة المعالجة المركزية بنسبة 100٪ عند اختفاء الطبقة 2. ربما لم يتم إرسال المزيد من بيانات المهام ، لكنها تحاول التخلص من حزم سجل نظام UDP ولا يمكنها ... مجرد تخمين ...

آسف ، نص طويل لسؤالين بسيطين ... باختصار:
المستوى الافتراضي: نعم ، لقد قمت بتعيينه على الحد الأقصى (100) أو نحو ذلك بشكل افتراضي ...
صفحة sysinfo وقواعدها: أقول لا ، لماذا يجب تغيير ذلك ديناميكيًا؟ إنها قيم طارئة ...

@ clumsy-stefan لقد قمت بالفعل بتعيينه على 50. فلننتظر. ؛)

wolverinevn hmm ... يجب أن يحدث 50 بسرعة كبيرة اعتمادًا على عدد المهام الفاصلة وإعادة المحاولة لديك (5-15 دقيقة.) ... إذا لم يساعد ذلك في اعتقادي أن العقدة غير مجمدة في الواقع ، ولكنها يمكن أن " ر إعادة الاتصال بالشبكة. كان لدي هذا أيضًا حتى بعد إعادة تشغيل WD. هل يمكنك معرفة ما إذا كانت العقدة تحاول الانتقال إلى وضع AP؟ هل ترى AP-WLAN الخاص بالعقدة؟

صفحة sysinfo وقواعدها: أقول لا ، لماذا يجب تغيير ذلك ديناميكيًا؟ إنها قيم طارئة ...

قصدت أن يتم فحصي في القواعد باستخدام متغير نظام مثل %conn_fail% وعرضه على صفحة sysinfo ، بجانب عدد مرات إعادة الاتصال بشبكة wifi.
بعد كل شيء ، إنها قيمة إحصائيات الأداء

قصدت أن يتم فحصي في القواعد باستخدام متغير نظام مثل٪ conn_fail٪ وإظهاره على صفحة sysinfo ، بجانب عدد مرات إعادة الاتصال بشبكة wifi. بعد كل شيء ، إنها قيمة إحصائيات الأداء

آه ، نعم ، توافق ، سيكون ذلك منطقيًا! هذا أيضًا مرتبط قليلاً بالمسألة رقم 1993. سيكون وجود مكون إضافي يرسل عددًا من متغيرات النظام / الأداء بانتظام إلى وحدة التحكم (دون إضاعة المهام المحدودة المتاحة) أمرًا رائعًا حقًا!

wolverinevn hmm ... يجب أن يحدث 50 بسرعة كبيرة اعتمادًا على عدد المهام الفاصلة وإعادة المحاولة لديك (5-15 دقيقة.) ... إذا لم يساعد ذلك في اعتقادي أن العقدة غير مجمدة في الواقع ، ولكنها يمكن أن " ر إعادة الاتصال بالشبكة. كان لدي هذا أيضًا حتى بعد إعادة تشغيل WD. هل يمكنك معرفة ما إذا كانت العقدة تحاول الانتقال إلى وضع AP؟ هل ترى AP-WLAN الخاص بالعقدة؟

لدي 9 مهام ، 3 منها وهمية و MQTT_import. أعتقد أن القواعد مشغولة قليلاً بالحوسبة وأجهزة استشعار القراءة ، حاولت الحد من mqtt_publish عن طريق استدعاء القواعد كل بضع دقائق. الحمل حوالي 29٪.
كما أتذكر ، آخر مرة تم تجميدها هذا الصباح ، لا يمكنني العثور على AP الخاص بـ Espeasy (إذا كنت تقصد أن AP_WLAN تعمل في وضع AP).
كان الإعداد (الشبكة ، موقع ESP) يعمل بشكل رائع مع Nodemcu آخر يعمل على 2.3 أو 2.4 والذي تم إصداره في مارس.

_Uptime 7 ساعات و 20 دقيقة ، RSSI هو -71 ديسيبل ، وهناك عدد قليل من شبكات wifi حولي.
سبب قطع الاتصال الأخير: | (200) مهلة الإشارة التنبيهية
يعيد الرقم الاتصال: | 35_

wolverinevn ، المشكلة في هذه المشكلة هي أنها تحدث عشوائيًا تمامًا. لديّ حوالي 30 عقدة قيد التشغيل ، وبعضها واجه المشكلة ، وبعضها لم يتم إعادة تشغيله ، والبعض الآخر في وضع AP ...

يبدو حقًا أنه مزيج من مدى انشغال العقدة ، ومدى انشغال الهواء (على سبيل المثال ، عدد أجهزة wifi) وكيفية تعامل AP الخاص بك بشكل حاد مع ظروف معينة (missnig layer 2 acks وما إلى ذلك) ...

لذلك أعتقد أنه حتى نجد طريقة داخل التطبيق (ESPEasy) لاكتشاف هذا الشرط بشكل موثوق والتصرف بناءً عليه ، لا يوجد حل "حقيقي" ....

wolverinevn PS: أنت لا تستخدم mikrotik AP بالصدفة؟

wolverinevn حول عدد مرات إعادة الاتصال (في تعديلك)
35 يعيد الاتصال في حوالي 8 ساعات كثير.
لدي عقد هنا تعمل لعدة أيام ولديها عدد قليل من عمليات إعادة الاتصال.
الأكثر استقرارًا يعمل لمدة 20 يومًا 11 ساعة و 46 دقيقة الآن وإعادة الاتصال مرة واحدة فقط.

متصل | 19 د 22 س 33 م
- | -
سبب قطع الاتصال الأخير | (202) فشل المصادقة
عدد يعيد الاتصال | 1

wolverinevn PS: أنت لا تستخدم mikrotik AP بالصدفة؟

لا. أنا أستخدم جهاز توجيه يعمل على تشغيل البرامج الثابتة Padavan (نوع من ASUS).

@ TD- إيه كنت أعرف ذلك. أنا أتفقد السبب ، قد يكون هناك ضوضاء من وحدة باك في مكان قريب. شخص آخر لديه 0 إعادة الاتصال بعد ساعتين.

لا. أنا أستخدم جهاز توجيه يعمل على تشغيل البرامج الثابتة Padavan (نوع من ASUS).

لسوء الحظ ، لا أعرف هذا FW على الإطلاق ... هل هناك فرصة لتعديل معلمات الطبقة 2؟ شيء مثل مهلات ack الإطار أو ما شابه؟ بعض إعدادات "المسافة" الرقيقة؟

@ clumsy-stefan لسوء الحظ ، لا أرى أي شيء من هذا القبيل.

@ clumpsy-stefan تم إعادة تشغيل الوحدة مرتين الليلة الماضية مع تعيين حد فشل 50. الخبر السار هو أنه لم يعد هناك تجميد. سأحاول اليوم تحسين اتصال wifi ببعض التغييرات الطفيفة في إعداد الأجهزة.

3 وحدات Wemos في نفس الغرفة ، متصلة بنفس نقطة الوصول.
إعادة الاتصال في آخر 16 ساعة أو نحو ذلك ،
مع القاعدة: على WiFi # متصل ....

26 إعادة تشغيل WD و 104 إعادة توصيل:

9 إعادة تشغيل WD و 32 إعادة توصيل

2WD عمليات إعادة التمهيد و 40 إعادة توصيل

كلها لديها 50 عتبة فشل محددة

Domosapiens & wolverinevn هناك شيء آخر يمكنك تجربته وهو زيادة مهلة مفتاح المجموعة على AP الخاص بك (إذا كان لديك مثل هذا الخيار). عادة ما يكون ذلك حوالي 5 دقائق. يمكنك محاولة زيادة 30 دقيقة. أو حتى ساعة واحدة ومعرفة ما إذا كانت تتحسن (طالما أنها ليست في شبكة أمان فائقة ، وهو ما لا أفترضه إذا كان لديك إنترنت الأشياء فيه) ...

@ TD- إيه

الأكثر استقرارًا يعمل لمدة 20 يومًا 11 ساعة و 46 دقيقة الآن وإعادة الاتصال مرة واحدة فقط.

لدي أيضًا وحدات تعمل حاليًا لأكثر من 3 أيام الآن وأخرى أعيد تشغيلها في غضون يوم واحد ...

لقد رأيت بعض المشكلات المتعلقة بإعادة طلب مفتاح المجموعة. يبدو بطريقة ما ، أنه في الإصدارات الأحدث من النواة ، يمكن أن يحدث أن تنتهي مهلة إعادة التشغيل ... ولكن يجب أن يعمل التطبيق على هذا ولا ينتقل إلى وضع تحميل عالي لا يستجيب ... لكنني لست كذلك اكيد اين فشل ..

@ clumsy-stefan شكرا على اقتراحك.
أرى في جهاز التوجيه dd-wrt الخاص بي معلمة. "Key Renewal Interval" بقيمة 3600 (بالثواني).
لذلك يجب أن يكون ذلك جيدًا؟

تنتهي مهلة إعادة الطلب

هذا من شأنه أن يفسر فقط إعادة توصيل imho كل ساعة.
بفضل ميزة القاعدة الرائعة _WiFi # Connected_ يمكننا رؤية هذا.
لا توجد فكرة عن كيفية أداء الإصدارات القديمة على هذا.
مشكلة خفية بالفعل لفترة طويلة؟

بعد ضبط مفتاح تجديد مجموعتي من 5 دقائق. إلى ساعة واحدة ، تعمل الوحدات بشكل أكثر استقرارًا. أفترض أنه مع 40 عميلاً متصلاً بنقطة وصول واحدة كل 5 دقائق. rekey أصبح الجو مشغولاً بعض الشيء .. بعد ذلك يمكنني حتى تقليل مهلة الإطارات مرة أخرى وأصبحت الوحدات أكثر استجابة مرة أخرى ، كما أنني حصلت على "مهلات اتصال" أقل بعد تغيير هذه المعلمات ...

@ TD-er ما زلت أعتقد أن "مهلة مفتاح المجموعة" و "فشل التجميع" بعد ذلك يجب أن يتم التقاطها والتعامل معها بواسطة التطبيق. لدي شعور بأن الوحدة تواصل محاولة إرسال رسائل في قائمة الانتظار إلى وحدة التحكم / الخادم أثناء محاولة إجراء إعادة مفتاح مما يجعل الوحدة بطيئة للغاية وفشل إعادة الطلب ... وبالتالي قطع الاتصال في الطبقة 2.

مع ذلك ، مجرد فكرة تقريبية ، ما زلت أحاول أن أعلقها حقًا ، لكن هذا هو أقرب ما يمكنني الحصول عليه حتى الآن.

@ TD-er jsut الآن لقد اختبرت مرة أخرى عقدة تدخل في حلقة غير محددة من محاولات إعادة الاتصال وتنتهي صلاحيتها دائمًا (انظر السجل أدناه). intersting هو أنه يدرك بوضوح أنه غير متصل ولا يحاول إرسال البيانات إلى وحدة التحكم ، مما يعني أن "محاولات الاتصال الفاشلة" لم تعد تزداد وبالتالي لا تصل أبدًا إلى حد الاتصال الفاشل.

يظهر أيضًا الحمل دائمًا بنسبة 100٪ ، ولهذا أعتقد أنه لا ينجح في إعادة الاتصال لأنه دائمًا ما يكون بطيئًا جدًا في القيام بالمصافحة بالفعل .... sems مثل عضة الذيل بالنسبة لي ... أفترض أنه يتعطل لأنه من المذكر) ...

سأقوم باختبار الرقم 2073 وأرى ما إذا كان هذا الموقف سيحدث مرة أخرى ... ومع ذلك ، فإنه نادرًا ما يحدث على العقدتين المتسلسلين المتصلين ، حتى أتمكن من تتبع ما يحدث بالفعل ...

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

من الصعب الاتصال بـ rssi - 80

لا يمكن الاعتماد على قيمة RSSI عندما لا تكون العقدة ESP متصلة! نفس العقدة لديها أقل من -70 عند الاتصال .... على عقد النوم العميق حتى أنها تظهر الافتراضي "غير متصل" عند +31 عند إرسال القيم!
وبعد إعادة التشغيل ، يتم تشغيله بدون مشاكل ... (بدون تحريكه ...) إذا قرأت أعلاه ، فهذه مشكلة من الطبقة الثانية قابلة للتكرار عند تعديل المعلمات على AP ....

ملاحظة: يمكنك تجربتها بنفسك! jsut قم بتوصيل 20-30 عقدة وخفض مهلة مفتاح المجموعة إلى 5 دقائق. وقيمة حد الرد على الإطار إلى شيء مثل 7 ... انظر ماذا يحدث!

أعتقد أنه مكان خاطئ للمشكلات المتعلقة بـ layer2 ، يجب عليك ملء المشكلة على esp8266 core أو ربما أفضل في مشروع nonos sdk
لكن من فضلك لا تصرخ هنا

يحدث ذلك فقط مع ESPeasy وليس مع أنواع البرامج الثابتة التي جربتها. أفترض أن العقدة تصبح مشغولة للغاية في وقت ما ولا تترك وقتًا كافيًا للجوهر لإجراء إعادة فتح المفاتيح (تم شرح كل شيء عدة مرات) ، لذلك لا تتردد في قراءة التنقيحات والتفسيرات ...
لكنني أتفق معك ، لست بحاجة للإجابة في الواقع ...
ملاحظة: @ uzi18 هل كان لديك 30 عقدة تعمل بنجاح في نفس الوقت؟

@ TD-er: في ESPEasyWifi.ino الأسطر 650 - 669 ، تنفصل المطابقة الافتراضية لكشف التبديل عن التبديل ، وبالتالي يُرجع true tryConnectWiFi() true على الرغم من أن WiFi.status() هو ليس بالضرورة WL_CONNECTED لكن يمكن أن يكون أي ولاية أخرى (يتم فحص حالتين خاطئتين فقط ..).

تغيير هذا وإرجاع true فقط إذا كان WiFi.status() عاد بالفعل WL_CONNECTED يحل واحدًا على الأقل من مشكلات فصل / استثناء الطبقة 2 التي أواجهها!

ما رأيك؟
هل أفتقد شيئًا ما أو لماذا يجب أن يعود tryConnectWiFi() WiFi.status() ليس كذلك؟ WL_CONNECTED`؟

@ clumsy-stefan من الجيد أن ترى أنك ما زلت تبحث في كود WiFi.

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

كانت الفكرة الأولية لهذه الوظيفة هي بدء تسلسل اتصال WiFi.
ربما تغيرت وظيفتها قليلاً خلال جميع التغييرات منذ ذلك الحين.
لكن قد تكون على شيء هنا.
أعتقد أنه قد يكون تغييرًا مناسبًا إلى return true (في نهاية هذه الوظيفة) فقط إذا أعادت الحالة أنه متصل.

هل يمكنك وصف ما يبدو أنه مشكلة الطبقة 2 الأخرى التي تواجهها؟

لا يمكنني تحديد وقت حدوث الاستثناء الآخر بالضبط ، ولكن على الأقل هناك فرق إذا كانت هذه الدالة تُرجع true عندما تكون الحالة WL_CONNECTED أرفق التصحيح قبل التغيير وبعده. .

قبل

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

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

بعد

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

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

حسنًا .. لقد أدركت أنه بعد هذا الوضع الداخلي لا (حتى الآن) يتطابق مع حالة Arduino ... قد يؤدي هذا أيضًا إلى مشكلات أعتقد ...

@ clumsy-stefan هذه الحالة هي لأنه لا يمكننا الاعتماد على حالة Arduino wifi ، ولهذا السبب قدم @ TD-er حالة ESPEasy ، ولكن حسنًا ، ربما يمكننا محاولة التحقق مما إذا كانت كل حالة في الكود قد تم فحصها بشكل صحيح.

يمكن أن تكون حالة wifi هذه قد تم إصلاحها في core 2.5.0 ، لذلك ربما أصبحت حالتنا الخاصة قد عفا عليها الزمن.
سيكون ذلك جيدًا ، لأنه يجعل رمز WiFi معقدًا إلى حد ما وبالتالي عرضة للأخطاء.

تعديل:
أنا أنظر إلى هذا الخطأ الذي قدمته:
Fatal exception 9(LoadStoreAlignmentCause):
أحد الإصلاحات الأكثر حداثة في core 2.5.0 يتعلق بمنشئ IPAddress ، والذي يجب أن يصلح المشكلات عندما لا تكون محاذاة تسلسل البايت المحدد متماشية مع 32 بت.
ربما هذا شيء مشابه؟

هذا أحد التخمينات التي لدي ، أن حالة ESPEasy ليست دائمًا متزامنة مع حالة Arduino. ربما لم يتم التعامل / تحقيق قطع الاتصال المؤقتة بشكل خاص على الطبقة 2 (مثل طلبات WiFi).

هناك شيء آخر يمكن أن يكون عكس ذلك ، وهو أن ESPEasy يعتقد أنه مفصول ويحاول إعادة الاتصال ولكن النواة لا تزال متصلة وبالتالي تؤدي إلى استثناء. لكن لا يمكن إثبات ذلك بعد ...

حول المحاذاة ، نعم ، يمكن أن تكون ، ولكن لا يمكن حل هذا أيضًا حاليًا ...

لذا فإن الشيء الوحيد الذي أنا متأكد منه حاليًا هو أن رمز الإرجاع tryConnectWiFi() يجب أن يتطابق مع حالة الاتصال الفعلية أو على الأقل التحقق من WL_CONNECTED ...

@ TD - إيه أنا أكثر قلقًا إلى حد ما

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) ويعيد التشغيل ...

تحرير: راجع للشغل ، يمكنك فرض هذا السلوك إذا طردت العقدة من نقطة الوصول يدويًا ... في بعض الأحيان يتم إعادة الاتصال فقط ، وأحيانًا يحدث ما تم وصفه أعلاه ...
EDIT2: في بعض الأحيان يتعطل مع الاستثناء 9 ... لذلك يبدو أنه نوع من حالة العرق كيف يتعافى بالضبط من انقطاع الاتصال! خطأي ، كان لديه addLog() في رد الاتصال onDisconenct() ...

إنها دائمًا نفس الحالة إلى حد ما. بعد فشل المصافحة رباعية الاتجاهات (rekeeying) لم يعد يتعافى بعد الآن ... لست متأكدًا من كيفية فرض استعادة هذا ..

على الأقل ، فإن إضافة بعض delay(100) في processConnect() و processDisconnect وبالتالي إعطاء الوقت الأساسي لتحديث حالة WiFi يجعل شبكات WiFi متزامنة مرة أخرى. هذا أيضًا يجعل الوحدات تدخل في الوضع أدناه أقل كثيرًا!

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

@ TD-er tryConnectWiFi() يعيد true أو false في حال كان الاتصال ناجحًا أم لا ... على الرغم من أن WiFiConnectRelaxed() لا يتحقق أبدًا من ذلك ...

هل هذه الوظيفة بطريقة ما من قبل شبكة WiFi القائمة على الحدث؟ يبدو أنه لا يصل أبدًا إلى آخر سطرين في هذه الوظيفة ...

نعم ، لقد كان نوعًا ما متبقيًا من قبل شبكة wifi القائمة على الحدث.
أعتقد أننا يجب أن نفكر حقًا في إلقاء نظرة فاحصة على رمز WiFi مرة أخرى ، لأنه ليس منظمًا كما ينبغي.

حسنًا ... ما زلت أقوم بتصحيح ما يحدث بالضبط بسبب مهلة المصافحة الرباعية ولماذا لن تعيد العقدة الاتصال مرة أخرى ... لكنني أعتقد أنني ما زلت أضغط قليلاً في الظلام ولكني أجد أجزاء صغيرة هنا و هناك والتي يمكن أن تضيف على الرغم من ....

يبدو أن واحدًا صغيرًا آخر موجود في WifiCheck() ... هناك التحقق من اتصال الطبقة 2 يتم فقط عندما يكون IP غير صالح (على سبيل المثال ، جميع الثماني بتات هي 0). قد يؤدي هذا إلى الحالة التي تكون فيها الطبقة 2 غير متصلة (أو تعيد) الاتصال / المصافحة ، وما إلى ذلك ، ولكن IP لا يزال صالحًا لأنه لم ينته بعد (DHCP). ربما يكون هذا هو السبب في أن "فشل تجديد DCHP ربما فشل" يحدث فقط بعد وقت طويل ، عندما ينتهي عقد الإيجار بالفعل ... لكنني ما زلت أتحقق من هذا ...

يوجد أيضًا wifiCheck() و WiFiConnected() و connectionCheckHandler() وكلها تقوم بنوع من التحقق من الاتصال وتتصل ببعضها البعض وكذلك resetWiFi() ظل ظروف معينة .. . خصوصا connectionCheckHandler() يبدو أنه يتم استدعاؤه فقط عند mqtt_reconnect_count > 10 . إذن ماذا يحدث في بيئة غير MQTT؟

ملاحظة: أنا فقط أقوم بتوثيق النتائج التي توصلت إليها هنا بالبحث عن مشكلات WiFi الأساسية ... لذلك أنا سعيد بأي أفكار تتعلق بها ، ولكن ليس من المتوقع بشكل ضروري ...

يجب أن يكون هناك نوع من حالة العرق الغامضة في مكان ما. عندما تبدأ AP في إعادة المصادقة أو إعادة الطلب في بعض الأحيان ، لا تحصل العقدة / النواة على وقت كافٍ لوحدة المعالجة المركزية لإكمال المصافحة أو يتم مقاطعتها أثناء القيام بذلك ، خاصةً على العقد ذات الإشارة المنخفضة (وبالتالي تستغرق المصافحة وقتًا أطول) .. . (انظر أدناه).

يبدو أن هذه الطلبات / عمليات إعادة التأكيد تولد حدث قطع اتصال من المركز ، على الرغم من أن النواة ستعمل على إعادة تفاوض تلقائي أو إعادة ربط (كما أفهم). ولكن بعد ذلك يبدو أن عملية المصافحة هذه تنقطع بواسطة آلة حالة ESPEasy حيث يتم تشغيل إعادة الاتصال اليدوي ... هذه العملية تكرر نفسها ولا تنتهي أبدًا (أو في بعض الحالات تولد wdt's) ..

` 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.status() نهاية الشيك بعد أن تبدأ المكالمة WiFi.begin() في إرجاع WL_DISCONNECTED . وفقًا للوثائق ، فإن هذا يعني "إذا لم يتم تكوين الوحدة في وضع المحطة". محاولة معرفة سبب حدوث ذلك أو ما إذا كان من المفيد بالفعل وضع esp بشكل واضح في وضع AP قبل استدعاء WiFi.begin()

لذلك ما زلت آمل في العثور على المشكلة الأساسية "الحقيقية" وراء حدوث هذه الأكشاك ... إذا كان الأمر كذلك (تقاطع الأصابع) أود أن أقترح ، أن أقوم بإجراء علاقات عامة مع جميع التغييرات لك (والآخرين) لمراجعتها ....

يرجى العلم أنني رأيت أيضًا الكثير والكثير من المواقف التي لم تكن فيها حالة WiFi.status() صحيحة.
لذلك ربما يكون لدى المكتبات الأساسية الآن إصلاحات ومن المحتمل جدًا أنني أخطأت أيضًا في مكان ما في جميع محاولات جعل شبكة WiFi تعمل بشكل مستقر.
كان هذا التصحيح صعبًا للغاية ، حيث لا يمكنني إعادة إنتاج هذه المشكلات بنفسي واضطررت إلى التصرف بناءً على تقارير من مستخدمين آخرين.
لدي مؤخرًا وحدة نمطية تتصرف أيضًا بشكل سيء فيما يتعلق بشبكة WiFi ، لذا فهذه هي وحدة اختبار WiFi المفضلة لدي. ولكن قد يكون أيضًا مؤشرًا على أن المشكلة ستزداد سوءًا عندما تكون بعض الأجزاء على وشك الانتهاء من المواصفات. على سبيل المثال ، مصدر الطاقة ، أو مكثفات الفصل المفقودة ، (أيضًا) آثار رقيقة من ثنائي الفينيل متعدد الكلور ، وتدريع أقل ، إلخ.

بالتأكيد ، لا يعني ذلك أنني أستبعد قضايا المخلفات الخطرة. لكن لدي حوالي 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 - ميجا |
المكتبات: ⋄ | ESP82xx Core 2_4_2، NONOS SDK 2.2.1 (cfd48f3)، LWIP: 2.0.3 PUYA support |
إصدار GIT: ⋄ | mega-20190110 |
الإضافات: ⋄ | 7 [عادي] [Sonoff POW R1 / R2] |
وقت البناء: ⋄ | 10 يناير 2019 03:01:19 |
اسم الملف الثنائي: ⋄ | ESP_Easy_mega-20190110_hard_SONOFF_POW_4M.bin |

لم تكن هذه هي المشكلة في الإصدار الأقدم (عندما كان لا يزال بإمكاني استخدام القناة 14 ولدي شبكة ssid المخفية الخاصة بي).

هل لديك قناة WiFi ثابتة أم أنها متغيرة؟
لقد كنت أقرأ على صفحة حل المشاكل في Tasmota وهم ينصحون بشدة بإصلاح قناة WiFi.
إذا كانت القناة 14 غير قابلة للاستخدام ، فقد يكون هناك شيء يتعلق بالإعدادات الإقليمية قد تغير في مكان ما ، حيث يُسمح فقط بالقناة 1-11 في جميع البلدان.
كما أن القنوات 1 و 6 و 11 هي في الواقع القنوات الوحيدة التي يمكن استخدامها دون تدخل من القنوات الأخرى.

تعمل القنوات 1-10 فقط ، وليس 11. انظر هذا: https://github.com/letscontrolit/ESPEasy/issues/1337#issuecomment -394118989

قناة الواي فاي ثابتة بالطبع.

يمكن أن تتداخل أي قناة من قنوات أخرى ، ولا توجد طريقة للتحكم فيها. الجحيم ، يمكن أن يكون هناك تداخل من نفس القناة.

راجع للشغل ، فيما يتعلق بالمشكلة التي أواجهها - حالة 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 ، لكن القنوات لم تتغير في الماضي.

Von: Gijs Noorlander [mailto: [email protected]]
جيسينديت: فريتاغ ، 11. يناير 2019 21:47
ج: Letscontrolit / ESPEasy
نسخة إلى: مشترك
Betreff: Re: [Letscontrolit / ESPEasy] [خطأ] [استقرار WiFi] استثناء ESP 3/29 عند فصل الطبقة 2 (# 1987)

هل لديك قناة WiFi ثابتة أم أنها متغيرة؟
لقد كنت أقرأ على صفحة حل المشاكل في Tasmota وهم ينصحون بشدة بإصلاح قناة WiFi.
إذا كانت القناة 14 غير قابلة للاستخدام ، فقد يكون هناك شيء يتعلق بالإعدادات الإقليمية قد تغير في مكان ما ، حيث يُسمح فقط بالقناة 1-11 في جميع البلدان.
كما أن القنوات 1 و 6 و 11 هي في الواقع القنوات الوحيدة التي يمكن استخدامها دون تدخل من القنوات الأخرى.
-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو قم بعرضها على GitHub https://github.com/letscontrolit/ESPEasy/issues/1987#issuecomment-453651579 ، أو تجاهل https://github.com/notifications/unsubscribe-auth/AomgSxPjVKWrp0MSQTtbESKxFqaPVgt90ks . https://github.com/notifications/beacon/AomgS_fhHQnmg1AdpX11mVL9yNra8S_kks5vCPgxgaJpZM4YDivP.gif

تمنح عناصر Mikrotik قوة كبيرة ولكن حتى الإعدادات الافتراضية لشبكة wifi ليست صحيحة.

• تأكد من عدم وجودك في إعدادات الأمان tkip وتمكين تشفير aes ccm فقط
• أدخل تحديثًا لمجموعة رئيسية مثل 30 دقيقة أو ساعة واحدة
• في القنوات يكون عرض القناة 20 ميجاهرتز وفي أي رأي ، قم بتشكيل النطاق B وانتقل فقط إلى G / N
• تم تعطيل قناة الامتداد
• يبدو أن تعطيل PMKID (موصى به إذا كنت في حالة هستيرية بشأن الأمن) يجعل Esp veeeery غير سعيد
• أضف بلدك إلى إعدادات wifi (أو شاهد ما هو الحد الأقصى لقوة نقطة الوصول لديك وخفض قوة الإرسال بمقدار 3). هذا غالبًا ما يعزز أداء wifi (أعلم أنه مضاد للبديهة)

ليس لدي قطع اتصال بشكل عام (إلا عندما كان لدي شيء PMKID)

سيكون من المفيد على أي حال نشر إعدادات AP على أي حال :-)

هذه نصائح جيدة. أنا على دراية جيدة بالشبكات على الرغم من أنني أكثر خبرة في mikrotik وقد قمت بتكوين كل شيء كما تقول باستثناء مفتاح المجموعة.

يتعلق تحديث مفتاح المجموعة فقط بمفتاح المجموعة ، وليس مع مفتاح الإرسال الأحادي حيث تكمن المشكلة أيضًا ، لكنني خفضت هذا الإعداد لأغراض التجربة.

@ 0ki Cool لم

لقد استنتجت أنه من الواضح أنه خطأ في برنامج ESPEasy. يمكنك رؤية السلوك الإشكالي على اليمين والذي يتطابق مع RouterOS الذي يقوم بفصل العميل الذي يعمل على سوء التصرف على اليسار. طيف الراديو واضح كما ترى.

لسوء الحظ ، ليس لدي الوقت الكافي للخوض في قاعدة بيانات ESPEasy في الوقت الحالي ، لكنني على ثقة من أن هذه المقارنة بين التواصل السيئ مقابل الجيد ستكون مفيدة.
وسيلة إيضاح: __red - نقطة الوصول | أزرق - espeasy | أخضر - جهاز آخر على شبكة iot الخاصة بي__

أعتقد أن ESP_easy لسبب ما قرر التبديل إلى وضع AP بعد تلقي استجابة مساعدة (الإطار 380 على اليسار) وعدم متابعة المصافحة الرباعية. لاحظ تغيير macaddress الخاص أيضًا - تتغير الثماني بتات الأولى من 80 إلى 82.

@ 0ki

لقد استنتجت أنه من الواضح أنه خطأ في برنامج ESPEasy.

أنا أيضًا ، لكن ليس لدي فكرة عن مكان الخطأ.
يبدو أن حالة ESPeasy الداخلية فيما يتعلق بالحالة غير المتصلة ليست متزامنة مع الحالة الحقيقية.
من المحتمل جدًا أنني ارتكبت خطأ ما في كتابة هذا الرمز ، أو أنه خطأ في المكتبات الأساسية.

ما هو الملف الذي تقصده تحديدًا بـ "هذا الرمز"؟ إذا أشرت إلى ملف أو ملفين ، يمكنني إلقاء نظرة عليه.

بخلاف ذلك - بما أنك الآن ترى اللحظة التي يحدث فيها ذلك بالضبط ، آمل أن تتمكن من إلقاء نظرة فاحصة عليها.

نظرًا لأنني أحفر في هذه المشكلة (لمدة شهرين تقريبًا) لم أعد متأكدًا تمامًا بعد الآن إذا كان رمز ESPEasy نفسه. مزيد من التفاعل بين ESPEasy و WiFi core / Library ... تظهر تصحيحاتي / سجلاتي أن "قطع الاتصال" يحدث دائمًا بعد تبادل / طلب مفتاح المجموعة. ولكن لا يتم استدعاء رد الاتصال إلا بعد انقضاء مهلة إعادة الطلب وبعد ذلك بعد فشل المصادقة ... لذلك أعتقد أن ESPEasy لا يترك وقتًا كافيًا لوحدة المعالجة المركزية إلى النواة للقيام فعليًا بإعادة الطلب ... حتى الآن لم أفعل لم أجد طريقة لمعرفة متى تكون العقدة في هذه العقدة أو في وضع إعادة المصادقة ، وبالتالي تكون قادرًا على إضافة ما يكفي من مكالمات delay() حتى يكون إعادة الطلب ناجحًا ...

للمساعدة في تحديد المشكلة في الوقت المناسب - كانت تعمل بشكل جيد مع:

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

وأعني حسنًا أنه لم يكن هناك فصل فقط ، ولكن أيضًا لم يكن الاتصال بـ AP المخفي على القناة 14 مشكلة.

@ clumsy-stefan ، أنا أؤيد تمامًا اكتشاف المشكلة التي تسبب انقطاع الاتصال في المقام الأول ، ولكن بصراحة ، قد يكون هناك عدد من الأسباب التي قد تؤدي إلى توقف اتصال wifi ، وبالطبع لا ينبغي أن يكون تبادل مفتاح المجموعة أحد الأسباب معهم.

المشكلة الأكثر إلحاحًا هي - لماذا لا يمكن إعادة الاتصال بعد قطع الاتصال. لا يمكن أن تكون مشكلة توقيت ، حيث إنني أعطي 5000 مللي ثانية للرد بالرسالة 2 من 4way HS.

أعتقد أن المشكلة هي أنك لا تحصل على قطع الاتصال إلا بعد فشل تبادل المفاتيح ... لذلك لم تبدأ الآن عندما تبدأ عملية التبادل فعليًا ، فهذا هو المكان الذي ستحتاج فيه إلى منح المزيد من الوقت للجوهر ...

في السجلات ، يمكنك أن ترى أن ESPEasy يعتقد لبعض الوقت أنه لا يزال متصلاً ، حتى لو لم يكن كذلك (حتى فشل اختبار الاتصال بالعقدة) ، لكن العقدة لا تزال تحاول إرسال البيانات (ومن الواضح أن الاتصال يفشل بعد ذلك) ...

المشكلة الثانية التي أوافق عليها تمامًا هي ، حتى لو حدث انقطاع في الاتصال ، فلماذا لا يمكن إعادة الاتصال بتسلسل اتصال جديد تمامًا ... من المحتمل أن تكون الوحدة أو النواة عالقة في حالة غريبة؟

تحرير: ملاحظة: فشل النظام المنسق 4way دائمًا ، (أفعل ذلك كل 10 دقائق) ، لذلك يبدو أنه مزيج من الحالة / الانشغال في ESPEasy والوقت الذي يحدث فيه النظام المنسق ..

ما يمكنني فعله هو محاولة إسقاط WiFi تمامًا (إيقاف تشغيل المودم أيضًا) والبدء في إعادة اتصال جديدة كاملة عند حدوث انقطاع غير متوقع.
لست متأكدًا مما إذا كان موجودًا في هذا الموضوع ، ولكن في إحدى هذه المشكلات ، رد شخص ما بتغريدة لشخص ما في Shelly ، الذي ذكر أنه كان عليه إعادة تشغيل مكدس wifi بالكامل بعد قطع الاتصال.

@ TD-er وهذا أيضًا ما أضعه في الإصدار الأخير. ضمن processDisconnect() أضفت setWifiMode(WIFI_OFF); غير متأكد ، إذا كان هذا كافيًا ... فهو يعمل حاليًا على بعض عقد الاختبار (منذ حوالي ساعة واحدة) ...

@ TD- إيه إنها فكرة رائعة. دفع إصدار git وسأومض عناصري!

لقد بدأت للتو في قراءة بعض من التعليمات البرمجية منذ 5 دقائق ، لذلك قد يكون هذا غير ذي صلة ، ولكن: تأكد أيضًا من تعيين wifi_connect_attempt على 0 في تلك المرحلة.

حسنًا ... يبدو أن إضافة بعض delay(0) في backgroundtasks() بعد كل من مكالمات الروتين الفرعي ، يزيد من استقرار المشكلة الأولى قليلاً (4way-HS). لست متأكدا إذا كانت صدفة صعبة ...
@ TD-er هل يمكن أن يكون ، أن backgroundtasks() يمنع التنفيذ في وقت ما؟

بشكل عام: يبدو أن إضافة delay(0) في جميع أنواع الأماكن المختلفة حيث تُظهر حالات التوقيت أوقات معالجة طويلة يؤدي إلى تحسين معالجة 4way-HS كثيرًا. لدي المزيد من حراس SW / HW الذين يبدأون العمل الآن أكثر من إعادة طرح المشكلات (ولكن لا يزال لديهم بعض) ... من حيث الأعراض ، لذا أود أن أقول إنه مرتبط حقًا بالجزء الأساسي / wifi الذي لا يحصل على دورات كافية للقيام بأشياء (سريعة جدًا) مثل إعادة الطلب ثم سئمت وكالة الأسوشيتد برس من انتظار إجابة ...

ما أراه أيضًا هو أنه في بعض الأحيان يمكن أن يستغرق client.connect() أو sendData() الكثير من الوقت (حتى ثانيتين). في بعض الوثائق ، وجدت أنه إذا استغرق شيء ما أكثر من 50 مللي ثانية ، فيجب عليك الاتصال بـ delay(0) ... لكن لا يمكنك تقسيم هذه المكالمات حيث يتم إجراؤها بواسطة المكتبة ...

هناك أيضًا رد اتصال آخر onStationModeAuthModeChanged في النواة. ربما يكون من المفيد النظر إليه ، حيث يتم تشغيل هذا الخطأ قبل حدوث قطع الاتصال الفعلي. لكنها قليلة التوثيق ... أي شخص لديه خبرة في هذا؟

تحرير: يبدو أنها حالة مصادفة / عرق مع بعض الأشياء الأخرى التي يتم القيام بها في الوقت الذي تطلب فيه وكالة الأسوشييتد برس إعادة إدخال .... ولكن مرة أخرى مجرد ملاحظات ...

لا أعرف عدد المرات التي يتم فيها إعادة إرسال هذه الطلبات التي أرسلتها AP.
عادةً ما يتم إرسال إشارة المنارة من نقطة الوصول كل 102.4 مللي ثانية. إذا استغرقت بعض المهام أكثر من ذلك ، فإن برنامج الثبات الإلكتروني يفقد أحد إطارات المنارة هذه. لذلك لست متأكدًا من مدى سوء هذا.
أعلم أن طلبات ARP يتم تفويتها في بعض الأحيان ، مما يؤدي إلى مشكلات لا يعرفها المحول بعد الآن كيفية توجيه الحزم إلى عنوان MAC هذا وبالتالي يجعل ESP غير قابل للوصول ، بينما لا يزال بإمكانه إرسال البيانات بنفسه.

إطارات المنارة المفقودة لا شيء. لا ينبغي أن يحتاج حتى إلى إطارات منارة لأنه يجب أن يبحث بنشاط عن شبكتي المخفية على أي حال.

أنا لست خبيرًا في WiFi.
كما فهمت ، فإن الفاصل الزمني للإشارة هو اللحظة الوحيدة المضمونة إلى حد ما التي يحاول ESP الاستماع إلى شبكة WiFi وسيحاول بينهما النوم قدر الإمكان.

وكما فهمت ، فإن الاختلاف الوحيد بين الشبكات "المخفية" والشبكات "غير المخفية" هو أن SSID لا يتم بثه. لذلك في الواقع يتم الاتصال فقط بناءً على BSSID (عنوان MAC لـ AP).
هذا أيضًا ما يفعله ESP عند الاتصال بشبكات WiFi (غير المخفية) ، مع الاختلاف الوحيد الذي سيجري مسحًا من قبل ومحاولة العثور على BSSID الذي يحتوي على SSID الذي يطابق الشبكة المحددة.
عند إجراء إعادة الاتصال تلقائيًا ، سيحاول أول مجموعة قنوات BSSID + معروفة دون إجراء فحص. بمعنى آخر ، يختلف الأمر فقط عند إجراء اتصال.

على حد علمي ، طالما كان هناك اتصال بشبكة ، فإنه سيستمع أيضًا إلى إطارات المنارة.

أنا لست خبيرًا في WiFi.
كما فهمت ، فإن الفاصل الزمني للإشارة هو اللحظة الوحيدة المضمونة إلى حد ما التي يحاول ESP الاستماع إلى شبكة WiFi وسيحاول بينهما النوم قدر الإمكان.

وكما فهمت ، الفرق الوحيد بين الشبكات "المخفية" والشبكات "غير المخفية" ..........

يا هذا يذكرني بشيء قد يكون مهمًا جدًا. أقوم بتشغيل ESPs في SSID مخفي
بالمناسبة ، لا يزال هناك انقطاع أو إعادة تشغيل على العقد الخاصة بي (محاولة 5 دقائق من تحديثات مفتاح المجموعة)

تمت إعادة تشغيل إحدى العقد الخاصة بي في الخامس من ديسمبر بسبب انقطاع التيار الكهربائي.

هذا من هذا:

الوحدة: | 5
- | -
التوقيت المحلي: | 2019-01-15 23:27:32
الجهوزية: | 41 يومًا 12 ساعة 46 دقيقة
تحميل: | 15.80٪ (LC = 9135)
مذكرة مجانية: | 12160 (5360 - sendContentBlocking)
المكدس المجاني: | 3552 (1520 - SensorSendTask)
التمهيد: | التمهيد البارد (0)
سبب إعادة التعيين: | النظام الخارجي
الشبكة ❔
واي فاي: | 802.11N (RSSI -67 ديسيبل)
تكوين IP: | DHCP
IP / الشبكة الفرعية: | 192.168.1.89 / 255.255.255.0
غيغاواط: | 192.168.1.1
IP للعميل: | 192.168.1.67
DNS: | 192.168.1.1 / 0.0.0.0
نطاق IP المسموح به: | كل المسموح به
STA MAC: | 5C: CF: 7F: B1: 3F: 12
AP MAC: | 5E: CF: 7F: B1: 3F: 12
SSID: | Lurch4 (34: 31: C4: B1: 8D: C7)
القناة: | 11
متصل: | 20 س 04 د
سبب قطع الاتصال الأخير: | (202) فشل المصادقة
يعيد الرقم الاتصال: | 61
البرامج الثابتة
بناء: ⋄ | 20102 - ميجا
المكتبات: ⋄ | ESP82xx Core 2_4_2، NONOS SDK 2.2.1 (cfd48f3)، LWIP: 2.0.3 دعم PUYA
إصدار GIT: ⋄ | ميجا 20181109
الإضافات: ⋄ | 46 [عادي]
بناء Md5: | 47f19d99d0c3f083314b45668b1f5c
فحص Md5: | تم الاجتياز بنجاح.
وقت البناء: ⋄ | 9 نوفمبر 2018 03:23:22
اسم الملف الثنائي: ⋄ | ESP_Easy_mega-20181109_normal_ESP8266_4096.bin

كما ترى ، في المتوسط ​​أكثر من قطع الاتصال في اليوم. وهو متصل بـ AVM Fritzbox 1750E

أعتقد أن إطارات المرشد ليست بالغة الأهمية ... ما زلت غير واضح لماذا بعد قطع الاتصال يفشل التسلسل العادي WiFi.begin() دائمًا مع '(2) Auth expire' .

المؤشر الوحيد هو أن تحميل وحدة المعالجة المركزية في هذه المرحلة يظهر دائمًا بنسبة 100٪ ويلمح إلى أن النواة لا تحصل على الوقت الكافي لمصافحة ...

أعتقد أن هناك شيئًا خاطئًا في المكتبات الأساسية (LWIP أو Arduino أو ESP) ويجب علينا إعادة ضبط wifi.
وبالتالي قم بإيقاف تشغيل wifi وابدأ من جديد. ربما تنتظر أيضًا بين هذه الخطوات للتأكد من إفراغ المخازن المؤقتة أو على الأقل مسحها وإلغاء الطلبات المعلقة.

@ TD-er هل يمكنك دفع هذا التغيير ، حتى أتمكن من معرفة ما إذا كان يعمل؟

التغيير الذي تمت مناقشته في آخر 2 وظيفة؟
لم يتم تنفيذه بعد ، لكن يمكنني أن أحاول هذا المساء ترميزه وإجراء اختبار.

نعم ، إعادة تعيين wifi.

كتب @ TD- إيه:

وبالتالي قم بإيقاف تشغيل wifi وابدأ من جديد. ربما تنتظر أيضًا بين هذه الخطوات للتأكد من إفراغ المخازن المؤقتة أو على الأقل مسحها وإلغاء الطلبات المعلقة.

لست متأكدًا من التنظيف ... نظرًا لأنني أزلت جميع المكالمات client.flush() قبل client.stop() يبدو أيضًا أن قطع الاتصال يحدث كثيرًا. أثناء قراءة بعض الوثائق ، رأيت أن التدفق ينسجم مع جميع مخازن الإدخال المؤقتة (tcp) ، لذلك من الناحية النظرية يمكن أن تضيع الردود ...

مجرد إضافة 2c الخاص بي ، لدي عدد قليل من نقاط الوصول Mikrotik ، مع عدد قليل من السونوفات التي تشغل espurna وعدد قليل من NodeMCUs التي تستخدم ESPEasy. اضطررت إلى إضافة نقطة وصول إضافية لأجهزة ESP ، لأنه خلال فترة حركة المرور المرتفعة في شبكتي ، مثل النسخ الاحتياطية ، سأفقد أجهزة ESP الخاصة بي. أعتقد أن هذا كان قوة إشارة WiFi وحركة المرور ذات الصلة. بمجرد إضافة نقطة الوصول الإضافية ، لا أتذكر رؤية هذه المشكلة مرة أخرى.

لكن أجهزة NodeMCU و ESPEasy الخاصة بي بها بعض قطع الاتصال. سأقوم بإعداد شاشة ping netdata للأجهزة ومعرفة ما إذا كان بإمكاني معرفة متى وكيف ولماذا قد يحدث هذا ومعرفة ما إذا كنت أعطي بعض المعلومات.

ملاحظة أخرى ، ليس لدي أكثر من 40 جهازًا مثل @ clumsy-stefan ، فقط حوالي 5 مستخدمين وأجهزتهم المحمولة والجهاز الذكي الغريب مثل التلفزيون ، ولكن هل يمكن أن يكون جهاز Mikrotik مثقلًا أو أن شبكة WiFi RF مشبعة ؟

أتمنى أن يكون لدي طريقة لمعرفة مقدار ضوضاء التردد اللاسلكي. لدي تطبيق (WiFi Analyzer) يعرض لي عدد نقاط الوصول وكيفية انتشارها لقنوات WiFi. لقد استخدمت هذه الأداة لتعيين قنوات WiFi الخاصة بي لمختلف شبكات WiFi AP.

لكن لا يمكنني معرفة ما إذا كان هناك تداخل آخر للترددات اللاسلكية.

بالنسبة لفكرة جهاز Mikrotik المحمّل بشكل زائد ، فأنا أستخدم MikroTik 951UI-2HND لجهاز التوجيه الرئيسي الخاص بي و MikroTik RB9412nD hAP lite بصفتي ESP AP.

أتساءل عما إذا كانت هذه المعلومات مفيدة بأي شكل من الأشكال؟

LeeNX شكرا للتلميحات. يتم توزيع العقد الخاصة بي على 3 نقاط وصول ويكون التردد اللاسلكي متوازنًا إلى حد ما (بحد أقصى 20 عميلًا لكل نقطة وصول أو نحو ذلك) ، بحيث يكون هناك أقل قدر ممكن من التداخل (بالطبع لا يمكن أن يكون هناك أي تداخل ...). لذلك لا أعتقد أن MTs مثقلة بالأعباء (أعمل في شركة توفر اتصالًا أساسيًا للشبكة و WLAN للأحداث المهنية ، وما إلى ذلك ، لذلك لدي بعض الاختبارات المتعمقة للبنية التحتية) ، لكنني أوافق على أن وقت الهواء الزائد يمكن أن تكون مشكلة ... ومع ذلك ، حتى لو كان الأمر كذلك ، فإن العقدة لا تتمكن أبدًا من إعادة الاتصال لأكثر من 250 مرة بعد قطع الاتصال ، ثم بعد إعادة تشغيلها تعيد الاتصال على الفور ، أعتقد أنه لا يمكن أن تكون مشكلة وقت البث ... لا أرى ذلك على أي جهاز آخر ...
لذلك ما زلت أعتقد أنها بعض المصادفة أو حالة السباق بين حالة شريحة wifi الداخلية ، ومقدار وقت وحدة المعالجة المركزية الذي تحصل عليه شبكة wifi الأساسية وما هي المهام الأخرى التي تعمل على جزء ESPEasy ...

@ clumsy-stefan أنا أتفق مع رؤيتك. أردت فقط أن أشير إلى أن استخدام Mikrotik AP الصغير مع أكثر من 40 عقدة ، يمكن أن يكون وحدة المعالجة المركزية Mikrotik أو ذاكرة الوصول العشوائي (RAM) محدودة ، ولكن لا يبدو أن هذه هي المشكلة.

إنني أتساءل عما إذا كان dpeloying جهاز ESP32 و NodeMCU مع أي شيء آخر غير نواة ESPEasy الأساسية وترك ذلك يعمل ، حتى نتمكن من اختبار وحدة المعالجة المركزية ESP وعدم وجود تأثير آخر للمكونات الإضافية. تعرف على ما يمكنني نشره واختبار ping netdata.

إذا أعطانا هذا أي معلومات مفيدة ، فسأقدم تقريراً.

شكرا يا رفاق !!!

لدي عقدة هنا تعمل بجوار لا شيء (IR RX / TX) وهي تعمل لأسابيع دون مشكلة.
العقدة الأخرى التي لديها وقت تشغيل يزيد عن 40 يومًا تعمل بنظام Domoticz MQTT و BME280 + MH-Z19 CO2.
لذلك من المحتمل أن يعتمد أيضًا على المكون الإضافي الذي يتم تشغيله وعدد المرات وربما أيضًا إذا كان الفاصل الزمني للقراءة يتطابق دائمًا مع فترة قراءة المكونات الإضافية الأخرى.

لقد قمت بالفعل بتعيين بعض استدعاءات الوظائف الدورية (10 / ثانية ، 1 / ​​ثانية و 30 ثانية) مع إزاحة أولية في المجدول حتى تستمر في العمل قدر الإمكان في مكالمات حلقة مختلفة.

ربما يجب علي أيضًا إضافة بعض أحداث المقاطعة المدفوعة بمؤقت مثل فعل تاسكر (أو ببساطة استخدم تاسكر بدلاً من المجدول الذي كتبته) وتعيين مهمة واحدة في فاصل زمني 10 مللي ثانية لتشغيل التأخير (0).
الشيء الوحيد هو أنه قد يقطع عمليات نقل GPIO الأخرى وبالتالي يزعج قراءات المستشعر.

من المحتمل أن يحل مشكلة 4way-HS ، لكن لا أعتقد أن مشكلة إعادة الاتصال ... لا تزال المشكلة الأكثر غرابة ... لقد فشلت عقدة الاختبار الخاصة بي مرة أخرى لمدة 12 ساعة في محاولة إعادة الاتصال لأكثر من 300 مرة بـ AP بدون نجاح. بعد إعادة التشغيل (soft-) ، تمت إعادة الاتصال على الفور (استغرقت إعادة التشغيل + إعادة الاتصال حوالي 5 ثوانٍ أو نحو ذلك) ...

لقد وجدت للتو هذه المشكلة التي تبدو مرتبطة تمامًا بما نراه هنا:
https://github.com/esp8266/Arduino/issues/5527

يبدو مشابهًا ، نعم ... ولكن لا يبدو أن استدعاء wifi OFF يغيره (جرب ذلك) ، حاليًا أحاول باستخدام WiFi.setOutputPower(0) قبل الاتصال بـ WiFi.begin() كما هو مقترح هنا
https://github.com/esp8266/Arduino/issues/2235
و هنا
https://github.com/esp8266/Arduino/issues/2186#issuecomment -233853152
ما زلت في انتظار حدوث ذلك الآن صعب ...

إنه مشابه ولكنه ليس هو نفسه. في حالتنا ، تؤدي إعادة تشغيل AP إلى حل المشكلة ، في المشكلة المنشورة بواسطة Gijs ، لا تؤدي إعادة تشغيل AP إلى حل المشكلة.

@ giig1967g إعادة تشغيل AP لا يحلها بالنسبة لي! فقط إعادة تشغيل العقدة تجعلها تعيد الاتصال مرة أخرى (في بيئتي) ...

@ giig1967g في المشكلة التي ذكرها https://github.com/esp8266/Arduino/issues/2235#issuecomment -248851270

لذلك يبدو أن لدينا العديد من القضايا هنا في متناول اليد.

@ stefan الخرقاء
آه طيب. وفي حالتي فقط مع Mikrotik ... :(
@ TD- إيه
ربما يجب أن تسأل عن ماركة / طراز AP ​​الذي يستخدمونه ...

@ giig1967g كان لدي أيضًا بعض العقد التي يتعذر الوصول إليها هنا ، لكن الفاصل الزمني لتلك الأحداث كان أكثر من 10 أيام ، لذلك من الصعب بعض الشيء تحديد ما إذا كانت مرتبطة بإحدى هذه المشكلات.
حوالي نصف العقد الخاصة بي متصلة الآن بـ Mikrotik والنصف الآخر متصل بـ Fritzbox 1750E

@ giig1967g أنا أيضًا أمتلك MT فقط ... ويبدو أنه يحدث في كثير من الأحيان للعقد ذات الإشارات والعقد الأضعف التي تستخدم GPIO (تحديدًا PCF) ...

أتمنى أن يكون لدي طريقة لمعرفة مقدار ضوضاء التردد اللاسلكي. لدي تطبيق (WiFi Analyzer) يعرض لي عدد نقاط الوصول وكيفية انتشارها لقنوات WiFi. لقد استخدمت هذه الأداة لتعيين قنوات WiFi الخاصة بي لمختلف شبكات WiFi AP.

لكن لا يمكنني معرفة ما إذا كان هناك تداخل آخر للترددات اللاسلكية.

يمكنك عمل /interface wireless registration-table print interval=1 على mikrotik الخاص بك لرؤية snr.

لسوء الحظ ، لم يساعد WiFi.setOutputPower(0) أيضًا ... بعد ما يقرب من 6 ساعات من التشغيل السلس (بدون أي تغييرات على البنية التحتية لشبكة wifi ، فجأة دخل في حالة الجمود مرة أخرى (انظر الإخراج التسلسلي أدناه) ولم يتعافى منه أبدًا ، إلا إذا كان بالصدفة أن تدخل SW أو HW WDT ...

يبدو أن هذا يحدث فقط بعد "انتهاء مهلة تحديث مفتاح المجموعة" أو "فشل تأكيد الاتصال الرباعي". إذا طردت العقدة من 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 مختلطة ، وكذلك كلا النطاقين 2/5 جيجاهرتز بما في ذلك AP الظاهري المحدد ... يتصل العملاء المختلفون بأوضاع مختلفة على نفس نقطة الوصول ، دون مشاكل (باستثناء esp8266) ..

أخبار جيدة (على الأقل بالنسبة لي) ... ركضت العقد الخاصة بي لمدة 12 ساعة الماضية دون انقطاع / إعادة تمهيد / تجميد!

يبدو أن إجبار العقدة على 802.11g يعمل بسلاسة مع MikroTik AP's. على الأقل هذا حل بسيط (طالما أنك لست بحاجة إلى السرعة الإضافية 802.11n).

إذا أراد شخص ما اختبار نفسه ، فقط أضف ESPEasyWifi.ino حول السطر 644 في الوظيفة tryConnectWiFi() السطر التالي (بعد setupStaticIPconfig(); ):
WiFi.setPhyMode(WIFI_PHY_MODE_11G);

لا يمكنني إلا أن أخمن أن المشكلات تُثار لأن وضع SoftAP لا يدعم 802.11n والعقدة متصلة في الوضع N ، حيث "يتم الخلط" بشكل ما في النواة ... ولكن أعتقد أن هذه مشكلة يجب طرحها مع الأشخاص الأساسيين. ..

بالنسبة لـ ESPEasy ، يمكن جعل هذا قابلاً للتكوين على ما أعتقد (@ TD-er؟) بحيث يمكن اختياره في صفحة التكوين أي الوضع يجب تشغيل ESP في (B / G / N) ...

نعم سأضيف خيار تحديد في الإعدادات المتقدمة.
لقد نسيت من سألها أولاً ، لكنني سأبحث عنه وسأفضله أيضًا في الالتزام ؛)

في احسن الاحوال!! لست بحاجة إلى الرصيد الذي أحتاجه فقط للعمل ؛) لذا لا تتردد في تكريسه له !! 😄

أثناء تصحيح لقد وجدت بعض الأشياء الصغيرة الأخرى التي أود أن أقترح أن التغيير (مثل الدعوة delay() دون قيد أو شرط بعد دعوات المساعد، وبعض إضافي {} وبعض الإضافات لانتاج قطع الأشجار. يجب أن أفعل العلاقات العامة ل هذه ASPIT أو هل تريد الاحتفاظ بها كما هي (أعتقد أن هذه ليست تغييرات حيوية فقط بعض التحسينات الطفيفة المحتملة)؟

يرجى تقديم العلاقات العامة.
سيساعد على الأقل المناقشة وتتبع نتائجك.
سيكون من المفيد أيضًا إضافة التعليقات إلى ما قمت بفحصه

للإشارة # 2012
جميع الاعتمادات إلى ديف. الفريق!

هل يتضمن هذا التصحيح أيضًا فكرة WiFi.setOutputPower (0)؟

أقوم بإجراء تجربة لمدة 7 أيام الآن.
عقدة mega-20180224 - صفر إعادة تمهيد
عقدة ميجا 20190110 - 35 إعادة تمهيد ؛ 9 منهم اليوم.

تركت السطر ذي الصلة في الكود لكنني علقت عليه. لذلك ستحتاج إلى إزالة // (حول السطر 644) في ESPEasyWiFi.ino وإعادة تجميعها!

oki آسف ، لقد رأيت للتو قرأت سؤالك بشكل خاطئ ... لا لم يتم تضمين هذا لأنني لم أتمكن من رؤية أي فرق عند تعيين الطاقة على 0 قبل إعادة الاتصال ... لذا فقد تجاهلت ذلك مرة أخرى!

أقوم بإجراء تجربة لمدة 7 أيام الآن.
عقدة mega-20180224 - صفر إعادة تمهيد
عقدة ميجا 20190110 - 35 إعادة تمهيد ؛ 9 منهم اليوم.

هذا يقارن بشكل فعال:

• الأساسية 2.3.0 بدون شبكة wifi على أساس الحدث
• الأساسية 2.4.2 مع شبكة wifi على أساس الحدث.

أخبار جيدة (على الأقل بالنسبة لي) ... ركضت العقد الخاصة بي لمدة 12 ساعة الماضية دون انقطاع / إعادة تمهيد / تجميد!

يبدو أن إجبار العقدة على 802.11g يعمل بسلاسة مع MikroTik AP's. على الأقل هذا حل بسيط (طالما أنك لست بحاجة إلى السرعة الإضافية 802.11n).

لقد فعلت ذلك في الاتجاه المعاكس للاختبار.
لقد قمت بضبط جهاز Mikrotik الخاص بي على الوضع N فقط وبصحة جيدة ... تعمل جميع أجهزة ESP منذ> 12 ساعة دون إعادة تشغيل واحدة.

نهج جيد وصحيح أيضا! لسوء الحظ لا يمكنني القيام بذلك ، لأنني أفعل عددًا من العملاء بدون قدرة N ...

فقط قم بتعطيل الوضع B وتمكين G / N فقط. أنت أفضل حالًا بدون الوضع B. ما لم يكن لديك هواتف قديمة أو (عادةً) أجهزة مسح ضوئي للرموز الشريطية على شبكة wifi من 10 سنوات مضت والتي تدعم فقط وضع B ومعدلاته.

كما أن الحساسية المضافة للهوائي في الوضع B لن تلعب أي دور مهم في المدى. يستهلك الوضع B وقت البث فقط. لا يوجد عيب حرفيًا في عدم استخدام الوضع B ولا يوجد عيب في استخدام الوضع N فوق G أيضًا. الوضع N له نطاق أفضل من B و G أيضًا.

@ jimmys01 أنت على حق ، ربما لم يعد الوضع B مستخدمًا في أي مكان بعد الآن ... لكن لا يمكنني استخدام N فقط على الرغم من ذلك ... لذلك سيكون الأمر

g / n غير مستقر بالنسبة لي.

هل هذا يعني أن esp8266 يواجه مشكلة في كل مرة ينتقل فيها بين الوضع (B / G / N)؟

هل هذا يعني أن esp8266 يواجه مشكلة في كل مرة ينتقل فيها بين الوضع (B / G / N)؟

من المرجح جدا.
لقد رأيت الكثير من المشكلات مع بعض الأجهزة (وليس أجهزة ESP) التي تدعم فقط وضع G.
إذا كنت تستخدمها ممزوجة بأجهزة N ، فقد يبدو أنها لا يمكن الوصول إليها.
تشتهر HomeWizard وبعض كاميرات WiFi.

مع هذا الإصدار الجديد mega-20190121 ، يبدو أن ESP أكثر استقرارًا ، ولم أواجه مشاكل التعطل / Wlan حتى الآن.
لكن الآن لا يمكنني إيقاف تشغيل OLED (بلوجين مؤطر) بعد الآن. عندما أرسل OLEDFRAMEDCMD ، فإنه يقوم بإيقاف تشغيل الشاشة للحظة قصيرة جدًا ثم يتم تشغيلها مرة أخرى.
لقد أجريت اختبارًا متتاليًا بإصدار قديم (من 2018) تستجيب الشاشة كما هو متوقع.

جربت للتو mega-20190121 واستقرار WiFi هو نفسه. إنه يتعطل في غضون ساعة تقريبًا من البدء.

@ TD-er ، متى تعتقد أنه يمكنك دفع إصدار مع التغيير الذي تمت مناقشته حتى أتمكن من اختباره؟

تحديث سريع: منذ ضبط إصلاح الوضع على 802.11g لم يعد لدي أي تجميد أو إعادة تمهيد وما إلى ذلك بعد الآن! على الرغم من أن AP تعمل في وضع g / n المختلط ... لذلك سأصوت أيضًا للتصحيح الذي يجعل وضع wifi قابلًا للتهيئة على esp!

نأمل في التصحيح قريبًا أيضًا 😉

لقد أضفت للتو التزامًا لاختيار B / G فقط.
إنه لا يعمل بشكل جيد حتى الآن على ESP32 ، لذلك قمت بتعطيل خيار تحديده لـ ESP32.
أضفت أيضًا خيارًا رجعيًا لتتمكن من الاتصال مرة أخرى إذا كانت نقطة الوصول لا تسمح بـ B / G فقط.

@ TD- إيه أعني هذا التغيير:

أعتقد أن هناك شيئًا خاطئًا في المكتبات الأساسية (LWIP أو Arduino أو ESP) ويجب علينا إعادة ضبط wifi.
وبالتالي قم بإيقاف تشغيل wifi وابدأ من جديد. ربما تنتظر أيضًا بين هذه الخطوات للتأكد من إفراغ المخازن المؤقتة أو على الأقل مسحها وإلغاء الطلبات المعلقة.

التغيير الذي تمت مناقشته في آخر 2 وظيفة؟
لم يتم تنفيذه بعد ، لكن يمكنني أن أحاول هذا المساء ترميزه وإجراء اختبار.

oki لقد جربت كلا المتغيرين ، مع ضبط طاقة الإخراج على 0 وفصل / إعادة الاتصال بنشاط عند حدوث المشكلة. لم يساعد كلا الإصدارين في إعادة تعيين / إعادة الاتصال بـ AP ... (في بيئتي) ... تفاصيل mre أعلاه ...
الشيء الوحيد الذي جعله مستقرًا هو استخدام الوضع N.

أنا مدرك لذلك جيدًا. أتمنى الحصول على تصحيح قريبًا ، حتى أتمكن من متابعة تصحيح الأخطاء.

@ 0ki يمكنني عمل testbuild لك باستخدام هذا الالتزام الأخير.
أو هل تريد أيضًا الاختبار مع تعطيل WiFi؟

وإذا كان الأمر كذلك ، فما هي الخيارات التي تريدها / تحتاجها؟ إيقاف تشغيل / تشغيل WiFi وإعادة تشغيل جميع الخدمات؟
هذا الجزء الأخير (خدمات إعادة التشغيل) هو أيضًا شيء يجب إلقاء نظرة فاحصة عليه ، لأنني لست متأكدًا تمامًا من إعادة تشغيل جميع الخدمات التي تستخدم المقبس بشكل صحيح.
قد يتسبب ذلك أيضًا في بعض المشكلات التي أعتقدها عند إعادة إنشاء اتصال WiFi.

إيقاف تشغيل جهاز إرسال wifi تلقائيًا (ثم تشغيله) عند اكتشاف انقطاع الاتصال.

أرى أنك أضفت بعض التعليمات البرمجية. ما الإصدار الذي يمكنني سحبه لاختبار ذلك؟

لست متأكدًا ، سأقوم بإنشاء بنية جديدة للاختبار.
سيتم ذلك في +/- 30 دقيقة.

بناء الاختبار
يعتمد على ما قمت بدمجه في وقت سابق اليوم و PR # 2235 الذي يحتوي على تغييرات للاتصال في وضع B / G.
يبدو أن هناك مشكلات في بعض المكونات الإضافية في تلك العلاقات العامة ، ولهذا السبب لم يتم دمجها بعد.

شكر! تومض بناء الاختبار.

لدي الآن الإعدادات التالية:
Connection Failure Threshold: 0 Force WiFi B/G: NO Restart WiFi on lost conn.: YES

هل تعتقد أنني يجب أن أختبر شيئًا مختلفًا بالنظر إلى أن لدي PLATFORMIO_ESP12E؟
وهذا يعني أنني لم أفهم ما إذا كان b / g سيعمل على esp12e وما هي عتبة فشل الاتصال بالضبط.

هذا الحد هو مجرد عداد لبدء إعادة التشغيل إذا كان عدد من محاولات الاتصال غير الناجحة يتجاوز هذه القيمة.
0 هو الإعداد الافتراضي ويعني أنه لن يقوم بإعادة التشغيل.

أعتقد أن ضبطه على 50 أو 100 سيساعدك على إعادة تشغيله عندما يكون في مكان يصعب الوصول إليه ويدخل في حلقة إعادة الاتصال.

حتى مع هذا الإعداد ، قد يستمر في إظهار عمليات إعادة تشغيل HW watchdog ، كما أظهر عدد من العقد الخاصة بي بالفعل.
قد يكون من الصعب إعادة إنتاج أولئك الذين لديهم وضع B / G نشط.

بناء الاختبار
يعتمد على ما قمت بدمجه في وقت سابق اليوم و PR # 2235 الذي يحتوي على تغييرات للاتصال في وضع B / G.
يبدو أن هناك مشكلات في بعض المكونات الإضافية في تلك العلاقات العامة ، ولهذا السبب لم يتم دمجها بعد.

شكرا لبناء الاختبار.
أصبح ESP12F الأكثر استقرارًا في السابق يعمل الآن منذ 59 ساعة بدون إعادة تشغيل :)

تحرير: الإعدادات هي:
فرض WiFi B / G: نعم
أعد تشغيل WiFi عند فقد الاتصال: نعم

أعتقد أنني سأقسم هذا الالتزام (B / G WiFi) إلى علاقات عامة منفصلة ، لذلك يمكن دمجها قبل أن أقوم بإصلاح بقية العلاقات العامة التي تنتظر دمجها الآن.

فكره جيده!

إعداداتي السابقة RestartWifi = لم تفعل شيئًا مفيدًا.

الآن تحولت إلى

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

وقد مر يومين دون إعادة تشغيل أو حتى فصل واحد. رائعة حقا. لا أعتقد أنني سأبتعد عن هذا الإصدار التجريبي.

بعد تقريبا. 100 ساعة قام النموذج أخيرًا بإعادة التعيين. :(

سبب إعادة التعيين: مراقب الأجهزة

ومع ذلك ، قد يحدث هذا أيضًا بسبب التكوين الصعب (12 مستشعرًا بسلك واحد وخادم FHEM).

يمكنك أيضًا محاولة إضافة هذا التصحيح: https://github.com/letscontrolit/ESPEasy/pull/2235/commits/9a05eaf828a737ae416ab11c8df8c4a5b03ceaf2
ربما سيساعد ذلك أيضًا في تحسين الاستقرار.
تم تضمينه في بناء الاختبار هذا

يمكنك أيضًا محاولة إضافة هذا التصحيح: 9a05eaf
ربما سيساعد ذلك أيضًا في تحسين الاستقرار.
تم تضمينه في بناء الاختبار هذا

شكر!
قم بتثبيته على وحدتين مختلفتين تمامًا وسيقدم ملاحظات.

تم تشغيله على إحدى عقد الاختبار الخاصة بي بما في ذلك
https://github.com/letscontrolit/ESPEasy/commit/9a05eaf828a737ae416ab11c8df8c4a5b03ceaf لسوء الحظ ، استغرق الأمر حوالي ساعتين فقط حتى واجهت مشكلة مهلة مفتاح المجموعة مرة أخرى ولم يتم التعافي أو إعادة الاتصال مرة أخرى إلى AP. مع تمكين "إعادة تشغيل wifi عند فقد الاتصال" وعدم إجباره على B / G .... لذلك لا يزال يبدو أن N يمثل مشكلة ..
بالنسبة لي ، لا يزال وضع B / G هو خيار العمل الوحيد المستقر.

هل يمكننا النظر في إسقاط دعم N تمامًا؟ هل نحتاج إلى المزايا التي يوفرها N لمثل هذا الجهاز البسيط؟

@ 0ki مع الخيار "الجديد" لفرض وضع B / G الذي تم

عند نقل هذا إلى الإعدادات الرئيسية ، أوصي بأن يتم شحن هذا الخيار بشكل افتراضي.

يمكننا أن نجعلها ديناميكية.
إذا لم يكن الاتصال ممكنًا ، فحاول مرة أخرى باستخدام الخيار N.

هناك الكثير من الإعدادات التي تم فحص N فقط في AP. لذلك في تلك البيئات لا يمكنك العودة إذا كنت تقوم بتعطيل دعم N على ESPeasy.

يمكنك أيضًا محاولة إضافة هذا التصحيح: 9a05eaf
ربما سيساعد ذلك أيضًا في تحسين الاستقرار.
تم تضمينه في بناء الاختبار هذا

شكر!
قم بتثبيته على وحدتين مختلفتين تمامًا وسيقدم ملاحظات.

حتى الآن ، تم إعادة تشغيل أحد النماذج بعد يومين ، والآخر بعد 5 أيام.
أظهر كلاهما "Hardware Watchdog" كسبب لإعادة التعيين.
تم تعيين كلا الوحدتين على "فرض WiFi B / G: نعم" و "إعادة تشغيل WiFi عند فقد الاتصال: نعم".
AP عبارة عن مجموعة Mikrotik على B / G فقط (وقت التشغيل 49 يومًا).
المسافة بين AP والوحدات تقريبًا. 2 ... 3 م.

كنت أتساءل لماذا حصل اقتراحي لجعله ديناميكيًا (للرجوع إلى N من إعداد B / G فقط) على "تصويتين" بقبول.
يرجى توضيح سبب عدم كونه اقتراحًا جيدًا.

كنت أتساءل لماذا حصل اقتراحي لجعله ديناميكيًا (للرجوع إلى N من إعداد B / G فقط) على "تصويتين" بقبول.
يرجى توضيح سبب عدم كونه اقتراحًا جيدًا.

في رأيي ، إذا قام شخص ما بتشغيل هذا الخيار ، فقد كان بالفعل يبحث بشدة عن مزيد من الاستقرار ويعرف ما يعنيه هذا بالنسبة لإعدادات AP الخاصة به.
أفضّل حلاً ثابتًا لأنني عندما أحدد خيار B / G فقط ، فأنا لا أريد مطلقًا أن أكون في موقف أعتقد أنه يستخدم B / G ولكن مرة أخرى لا.
ومع ذلك ، نظرًا لأن العقد الخاصة بي تعيد التشغيل على أي حال (على الرغم من أنها أقل تكرارًا) ، فإنني أرغب في الحصول على حل حقيقي للمشكلة المتعلقة بالنواة الأحدث.

لقد فهمت ذلك ، ولكن عليك أيضًا فهم المشكلة عندما لا يعرف المستخدمون ما يفعله الإعداد وينتهي بهم الأمر بعقد لا يمكن الوصول إليها.
لذلك يجب أن يكون لها حد كبير قبل العودة إلى دعم N.
على سبيل المثال ، تراجع المكونات الإضافية التالفة هو:
بعد 10 عمليات إعادة تمهيد غير ناجحة ، سيتم تعطيل مكون إضافي أو وحدة تحكم واحدة لمعرفة ما إذا كانت إعادة التشغيل قد تكون ناجحة.

يمكن أيضًا تطبيق شيء مشابه على اتصال 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

من الواضح أنه تم تنفيذه بالفعل للسماح لـ N فقط عندما يكون wifi_connect_attempt > 10.
تتم إعادة تعيين هذا العداد إلى 0 بمجرد أن تكون هناك محاولة ناجحة للاتصال بشبكة wifi.

هل هذا حل مقبول؟

حسنًا ، الأسابيع القليلة الماضية من وقت أقل لـ ESPeasy قد حجبت ذاكرتي عما خططت لتنفيذه أو ما تم تنفيذه.

لقد نظرت للتو في الكود الخاص بهذا ووجدت:

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

من الواضح أنه تم تنفيذه بالفعل للسماح لـ N فقط عندما يكون wifi_connect_attempt > 10.
تتم إعادة تعيين هذا العداد إلى 0 بمجرد أن تكون هناك محاولة ناجحة للاتصال بشبكة wifi.

هل هذا حل مقبول؟

حسنًا .. أود أن أقول نعم (آمل أن يتم العثور على الخطأ في 2.5.0 قريبًا).

تعليقات على إعداد B / G فقط.
لقد قمت للتو بتثبيت الاختبار fw على وحدة واحدة يتم إعادة تشغيلها كل 20 دقيقة آخر مرة. قبل توصيله بـ N بـ -72dBi. كان ينبغي أن يكون هذا إشارة جيدة بما يكفي لعدم قطع الاتصال. أنا أقوم بتشغيل AP على مستوى المؤسسة مع إمكانات استقبال -105dBi. لذا مرة أخرى يجب ألا تسقط القناة.

بعد بضع ساعات من اختبار FW ولم تتم إعادة التعيين حتى الآن.
سأبقيها قيد التشغيل وأعيد الإبلاغ.

ملاحظة: أوافق على أنه مرتبط بـ N بطريقة ما.
PSS: أقوم بتشغيل 20 عقدة من نوع ESP-07 تمت ترقيتها إلى 4 أمتار. تستغرق وقتًا طويلاً ولكنها تسدد عند الحاجة إلى إعادة الوميض.

لدي أكثر من 120 عقدة تعمل جميعها على GN (ميجا 20190202) بدون مشاكل على الإطلاق. إنهم جميعًا يبلغون عن الاتصال بـ N

@ jimmys01 كم عدد العقد التي تتصل بنفس نقطة الوصول؟
وما هي ماركة AP؟ (ميكروتيك؟)

يتصل جميعهم تقريبًا بنقطة وصول مختلفة (واحدة لكل غرفة في الفندق) ولديهم مفتاح (مستشعر PIR) ومستشعر درجة حرارة ورطوبة HTU ومصابيح الأشعة تحت الحمراء.
العلامة التجارية AP هي Mikrotik.
الإعدادات كما يلي:
تم تعيين البلد
قناة التحكم: 20 ميجا هرتز
الفرقة: GN
قناة الامتداد: معطل
نوع المصادقة: WPA2 PSK فقط
التشفير: aes ccm فقط
تشفير المجموعة: aes ccm
تحديث مفتاح Groyp: 00:01:00

تعليقات على إعداد B / G فقط.
لقد قمت للتو بتثبيت الاختبار fw على وحدة واحدة يتم إعادة تشغيلها كل 20 دقيقة آخر مرة. قبل توصيله بـ N بـ -72dBi. كان ينبغي أن يكون هذا إشارة جيدة بما يكفي لعدم قطع الاتصال. أنا أقوم بتشغيل AP على مستوى المؤسسة مع إمكانات استقبال -105dBi. لذا مرة أخرى يجب ألا تسقط القناة.

بعد بضع ساعات من اختبار FW ولم تتم إعادة التعيين حتى الآن.
سأبقيها قيد التشغيل وأعيد الإبلاغ.

ملاحظة: أوافق على أنه مرتبط بـ N بطريقة ما.
PSS: أقوم بتشغيل 20 عقدة من نوع ESP-07 تمت ترقيتها إلى 4 أمتار. تستغرق وقتًا طويلاً ولكنها تسدد عند الحاجة إلى إعادة الوميض.

لسوء الحظ ، تستمر الوحدة في إعادة التعيين بعد وقت عشوائي. أي شيء خلال 1-4 ساعات.
B / G only FW لا يحل مشاكلي

كنت أتساءل لماذا حصل اقتراحي لجعله ديناميكيًا (للرجوع إلى N من إعداد B / G فقط) على "تصويتين" بقبول.
يرجى توضيح سبب عدم كونه اقتراحًا جيدًا.

لنفترض أن شبكة 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 (ميجا 20190202) بدون مشاكل على الإطلاق. إنهم جميعًا يبلغون عن الاتصال بـ N

كيف تقوم بتحديث أكثر من 120 عقدة في إطار زمني مقبول ؟؟
"..لا توجد مشكلات على الإطلاق ..." هل تحققت من وقت تشغيل كل عقدة وما هو؟
هل جميعها متشابهة منذ آخر إعادة تشغيل مقصودة؟

تحسب أوقات الجاهزية الأيام وكلها لا تحتوي على أي إعادة اتصال. شهور حتى الآن لم أواجه أي مشاكل مع الاتصال إلا عندما قمت بتعطيل PMKID على نقاط الوصول. من المحتمل أن النواة الأحدث أصبحت أكثر انتقاءً فيما يتعلق بإعدادات wifi أو لا أعرف ماذا .. أنا أيضًا أقوم بتشغيل كل من لديهم مصادر طاقة 2A. نخطط في الشهر المقبل لنشر 80 جهاز إضافي esp8266. بالمناسبة ، إذا كنت تريد الحصول على وصول لإلقاء نظرة على الإعداد المحدد ، يسعدني أن أقدمها لك. أريد حقًا أن يزدهر 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 بنفسي مؤخرًا

وفقط إشعار حول يبني Core 2.5.0.
في الإنشاءات الليلية القادمة ، لم يتم تضمين إصدارات 2.5.0 ، نظرًا لوجود خطأ في النواة 2.5.0 مما يجعل خادم الويب يتوقف عن الاستجابة ويترك العقدة تتعطل.
بمجرد إصلاح ذلك ، سيكون هناك بنى أساسية 2.5.0 مرة أخرى.
في آخر إصدار ليلي ، يوجد 2.6.0 alpha أساسي مضمن ، وهو في الأساس أحدث كود من github للمكتبة الأساسية حتى تتمكن من رؤيته بنفسك.

حصلت على 2.6.0 مع B / G تعمل فقط منذ 4 أيام على وحدتين والأولى أعيد تشغيلها.
كان سبب إعادة التعيين هو "مراقبة الأجهزة" المعتادة.
ما لاحظته نظرًا لأن وضع "B / G" الوحيد نشط هو وقت تشغيل يبلغ 3..5 أيام قبل حدوث إعادة التعيين.

ربما تقارن أيضًا عدد قطع الاتصال بشبكة wifi ، حيث يبدو أن هذه الانقطاعات مرتبطة بالأعطال.

كلا الوحدتين في القبو ، على بعد 2..3 متر فقط من Mikrotik AP.
لقد راجعت للتو الوحدة الثانية التي تشغل نفس إصدار FW وهي تُظهر 0 إعادة الاتصال و 4 d02h وقت التشغيل (لا يوجد إعادة تشغيل منذ الوميض).
أؤمن بشدة أن الوحدة الأخرى ، التي قامت بإعادة التعيين. أيضًا لم يعيد الاتصال قبل إعادة تعيينه.

فيما يتعلق بالمهام التي تم تكوينها في وحدتي الاختبار:
تحتوي الوحدة التي تمت إعادة تعيينها على 12 جهاز استشعار DS18B20 تم تكوينها بحيث ترسل قيمتها كل 120 ثانية إلى خادم FHEM.
تحتوي الوحدة النمطية التي لم تتم إعادة تعيينها حتى الآن على اثنين فقط من وحدات gpios التي تم تكوينها والتي ترسل أيضًا قيمتها كل 120 ثانية إلى نفس خادم FHEM.

لذا ، فإن AP (Mikrotik) هي نفسها ، والمسافة (2..3mm) هي نفسها ، وخادم FHEM هو نفسه - فقط الوحدة التي تحتوي على 12 مستشعرًا لدرجة الحرارة تتم إعادة تعيينها بشكل متكرر أكثر من تلك التي تحتوي على 2 gpios.

يحدث هذا على العقد الخاصة بي بشكل أساسي عندما يكون fhem بطيئًا جدًا في الاستجابة أو لا يمكن الوصول إليه لأنني حددت إعادة محاولة بحد أقصى 100 ثم إعادة تشغيل العقد (والتي تظهر أيضًا إعادة تشغيل يدوية بعد ذلك).

يحدث هذا على العقد الخاصة بي بشكل أساسي عندما يكون fhem بطيئًا جدًا في الاستجابة أو لا يمكن الوصول إليه لأنني حددت إعادة محاولة بحد أقصى 100 ثم إعادة تشغيل العقد (والتي تظهر أيضًا إعادة تشغيل يدوية بعد ذلك).

لماذا يجب إعادة تشغيل العقد الخاصة بك عندما تكون عمليات إعادة المحاولة أكثر من 100؟
(لقد قمت بتعيين عمليات إعادة المحاولة على 0 للاختبار)

أدوات -> متقدمة -> عتبة فشل الاتصال

للتأكد من أنه في حالة اختناق wifi على الوحدات لسبب ما ، يتم إعادة التشغيل بعد مرور بعض الوقت ...

آه مع "عمليات إعادة المحاولة" تعني "عتبة فشل الاتصال:" وليس "إعادة المحاولة القصوى:" في إعدادات وحدة التحكم في FHEM.
لقد قمت بتعيين حد فشل الاتصال على 0.

راجع للشغل: للمرة الأولى كان لدي عقدة عالقة في مشكلة المهلة 4WHS على الرغم من أن "B / G فقط" كان نشطًا ... لم يكن لدي ذلك من قبل حتى الآن (تجميع ذاتي ، 2.5.0 نواة) .... سأستمر في مشاهدة هذا ، إذا كانت هذه مجرد صدفة ...

يرجى ملاحظة أنه سيكون هناك 2.5.1 نواة قريبًا جدًا والتي ستعيد SDK المستخدم إلى SDK2.2.1 ، نظرًا لوجود الكثير من المشكلات في SDK3.0.0
قد يؤدي هذا أيضًا إلى تغيير كيفية تفاعل العقد على wifi وربما يمكن مقارنتها بالنواة 2.4.2 مرة أخرى.
لست متأكدًا من الإصلاحات التي تم تضمينها في Core 2.5.0 والتي قد تعمل على إصلاح بعض المشكلات الأخرى التي نواجهها.

@ chunter1 حول العقد التي لديك.
يبدو أن الرسالة التي أعيد تشغيلها كانت ترسل الكثير من الرسائل إلى وحدة التحكم ، لذا من الناحية الإحصائية ، لديها فرصة أكبر لمحاولة إرسال شيء يتعطل في مكان ما أثناء العملية.

@ clumsy-stefan هل يمكنك اختبار الكود الحالي على جيثب؟ (أو أحدث بناء)

لقد أجريت بعض التغييرات في كيفية أداء النشاط المرتبط بالشبكة.

هل تقصد هذا؟

ESP_Easy_mega-20190227_test_core_260_sdk3_alpha_ESP8266_4M.bin

فقط عن أي بناء الليلة الماضية.
أضفت أيضًا إصدارًا "عاديًا" للنواة 2.6.0 باستخدام SDK2.
يتم تشغيل Core 2.6.0 SDK2 الآن على عدة عقد ولم يكن لديه سوى مراقب HW على أحدها وهو منخفض بشكل استثنائي في الموارد (يعمل بالكثير من المكونات الإضافية للذاكرة العالية) وأيضًا الذي يحتوي على ذاكرة فلاش متهالكة (يجب تخلص من ذلك بعيدًا نظرًا لأنه يحتوي على آلاف تحديثات البرامج الثابتة)

@ TD-er لقد قمت بتجميع وتثبيت من git منذ حوالي 6 ساعات على 2test nodes .. ولكن بما أنني لا أزال أمتلك وصولاً محدودًا للغاية إلى الإنترنت ، فربما يمكنني الإبلاغ فقط في غضون 24 ساعة لذا ...

لقد قمت باختبار أحدث البرامج الثابتة باستخدام "Force B / G mode" باستخدام جهاز التوجيه Mikrotik ويبدو أنه يعمل بشكل مستقر حتى الآن. سوف يقدم تقريرا.

@ TD-er سؤال واحد: ما هي قاعدة الرجوع إلى الوضع N عند تعيين "وضع القوة B / G"؟

@ giig1967g
إذا فشلت في الاتصال لأكثر من 10 مرات بنقطة الوصول باستخدام _B / G فقط_ ، فسوف تعود إلى وضع BGN الافتراضي.

لذا فإن هذا يترك إمكانية الاتصال في الوضع N إذا كانت نقطة الوصول غير متصلة ببعض الوقت.
إذا كان يبدو أن هذه مشكلة حقيقية ، فيمكنني محاولة ضبطها للقيام بذلك فقط كل 10 محاولة ، ولكن بعد ذلك يجب أن أتأكد من أنها ستحاول ذلك أيضًا عند تجربة ssid الاحتياطي.

مرحبًا @ TD-er
أعتقد أن الرجوع فكرة سيئة.
انظر إلى هذا السيناريو: لقد أجبرت وحدتي على تشغيل وضع B / G بسعادة مع جهاز Mikrotik.
لسبب ما ، أصبح جهاز Mikrotik غير متصل بالإنترنت (التحديث ، إعادة التشغيل ، أيا كان).
في أي وقت يظهر mikrotik مرة أخرى ، سيتصل ESP بعد ذلك في الوضع N وفقدت استقرار الوحدة.

بمعنى آخر ، إذا قمت بتعيين وضع Force B / G وفشل الاتصال ، فيجب أن يصبح AP (192.168.4.1) ، ولكن لا ينبغي الرجوع إلى الوضع N. تخلق الاحتمالية الاحتياطية توقعات خاطئة للمستخدم.

لا تأخذني على نحو خاطئ ، فالرجوع كان جيدًا لاختبار صلاحية التغيير ، ولكن الآن بعد أن أثبت أنه يحل المشكلة (على الأقل أنا حتى الآن) ، يجب إزالة الاحتياطي.

أوافق على تعليق @ chunter1 : https://github.com/letscontrolit/ESPEasy/issues/1987#issuecomment -462295204

ما رأيك في السيناريو التالي بعد ذلك.
بمجرد أن يكون من الممكن الاتصال بنقاط الوصول المحددة باستخدام B / G فقط ، سيتم تعيين علامة إضافية لعدم توفير أي احتياطي بعد الآن.
إذا تغيرت بعض هذه الإعدادات (B / G فقط ، أو إعدادات AP الأخرى) ، فسيتم تمكين الرجوع مرة أخرى حتى ينجح الاتصال بـ AP المحدد.

تعديل:
أعني بالرجوع تلك الإعدادات الإضافية ، وليس "SSID الاحتياطي"

بمعنى آخر ، يظل الإجراء الاحتياطي نشطًا فقط حتى أول اتصال ناجح بـ AP ، ثم يتم إزالته. في هذه الحالة ، سيكون من المفيد رؤية وضع wifi في صفحة النظام.
إنه حل ممكن حتى لو كنت ما زلت أفضل تجنب الرجوع إلى N إذا قمت بتعيين Force B / G.
أتفهم إمكانية قيام المستخدم بارتكاب أخطاء ، ولكن بعد ذلك يمكن للمستخدم كتابة SSID بشكل خاطئ وعدم الوصول إلى الوحدة في أي حال ...

مهمة أخرى: في التنفيذ الحالي في أي سيناريو ستصبح الوحدة AP؟
لأنه يبدو لي أن الوحدة ستحاول B / G لمدة 10 مرات ثم تحاول N ولكن هل ستستسلم في النهاية وتصبح AP؟

كلا ، يظل وضع AP نشطًا أثناء الاختبار للاتصال بنقاط الوصول المحددة.
ربما يجب أن نضيف أيضًا فحصًا اختياريًا لوقت التشغيل والسماح فقط ببدء وضع AP في أول 10 دقائق يتم تشغيل العقدة.
فقط لمزيد من الأمان وأيضًا لاستبعاد احتمال تأثير وضع AP على عدم قدرة ESP على الوصول إلى شبكات wifi المحددة.

وعلينا أن نواصل التركيز على الجزء "السهل" من المشروع.
هذا يعني الإعدادات الافتراضية المناسبة وعدم توفر قدر هائل من الإعدادات ، ولكن أعط الخيار للخبير للقيام بكل ذلك.
هذا يعني أيضًا أنه يجب أن يكون هناك تراجع مناسب للمستخدم الأقل خبرة.
خاصة بالنسبة لإعدادات B / G فقط. أعتقد أن أكثر من 90٪ من الأشخاص الذين بدأوا بـ ESPeasy ليسوا على دراية بالاختلافات بين 802.11B / G / N ، لذا إذا واجهوا مشكلات ، والتي يمكن التعامل معها جيدًا باستخدام احتياطي ، فقد يتسبب ذلك في البحث عن مشاريع أخرى .
أفهم أيضًا سبب عدم إعطاء هذا الإجراء الاحتياطي إحساسًا زائفًا بـ "الاستقرار" ، لذلك أفهم حقًا سبب وجود مجال للتحسين في التطبيق الحالي. ولكن إذا تم إجراء "أول محاولة اتصال ناجحة => تعطيل احتياطي" تلقائيًا ، فهي أيضًا مثالية للمستخدم الأكثر خبرة. (من يرتكب أخطاء غبية أيضًا ، كما أعلم من التجربة ؛))

أوافق على أنه يجب توضيح ما هو إعداد الاتصال المستخدم بشكل نشط.

يفهم.
إذن ، فإن الدعوى هي:
الوحدة أحذية.
تم تعيين علامة N- الاحتياطية على "صواب".
إذا تم تعيين FORCE B / G ، فإنه يحاول 10 مرات الاتصال بـ wifi AP في B / G.
إذا كان بإمكانه الاتصال ، فإنه يضبط N-backback flack على false.
إذا تعذر عليه الاتصال ، فإنه يحاول في الوضع N.

يرجى النظر أيضًا في هذا السيناريو مع مجموعة Force B / G: انقطاع التيار الكهربائي.
تم إيقاف تشغيل جهاز توجيه ESP و Wifi.
ثم تعود الطاقة ، ويكون ESP أسرع من جهاز توجيه wifi.
في هذه الحالة ، قد يحدث أنه بعد 10 مرات لا يزال wifi AP لا يستمع.
لذلك ستحاول الوحدة وضع N وستنجح في النهاية.
(من ذوي الخبرة) لن يعرف المستخدم أن الاتصال كان في الوضع N ويعتقد أنه في وضع B / G مع عدم الاستقرار.

لا أريد الإصرار ، ولكن في الحقيقة هذه القضايا HW والتجميد مستمرة منذ عام واحد. الآن بعد أن عثرت بمساعدة المجتمع على حل عملي واحد ، أنصح بشدة بالتأكد من استمرار تطبيقه. خطر قيام مستخدم غير متمرس بتعيين "وضع القوة B / G" أقل من قيامه بتعيين SSID خاطئ بنفس النتائج: لا يوجد وصول إلى نقطة الوصول.

اقتراح:
للتأكد من أن المستخدم الأقل خبرة لا يخطئ ، لماذا لا تضيف زرًا إلى "اختبار B / G mode". إذا نجح ، فإنه يمكّن "FORCE B / G mode" ، إذا لم يكن كذلك فإنه يظل معطلاً.

في هذه الحالة ، سيعرف المستخدمون الأقل خبرة ما يفعلونه وسيتأكد المستخدمون الأكثر خبرة من أنه عند ضبط وضع ForceB / G ، لا يمكن الرجوع إلى N.

ما رأيك؟

يمكنك

ليس فقط إذا تم تشغيله ، ولكن سيتم تعطيل خيار الرجوع في الإعدادات وحفظه.

حسنا. ثم يكون الفحص اليدوي أكثر ملاءمة بدلاً من الفحص التلقائي. ألا تعتقد ذلك؟

نعم ، سأضيف أولاً علامة اختيار بسيطة لتعطيل التجاوزات.
ولكن في وقت لاحق يجب أن تصبح أكثر ديناميكية في هذا لمساعدتنا أيضًا ، "الخبراء" على ارتكاب أخطاء أقل :)

حسنا

كان الإصدار 2019_02_16 يعمل الآن لمدة 9 أيام دون إعادة تشغيل (فرض على B / G). بالأمس بدأت في إعادة التشغيل مرة أخرى. أجبرت وكالة مراقبة الأجهزة هذا مرتين.
بعد فترة لم يعد من الممكن الوصول إلى الوحدة. لم يساعد تبديل جهاز التوجيه WLAN (جربه 3 مرات ، حتى 30 دقيقة). لم يساعد أيضًا إعادة تشغيل ESP عن طريق تبديل فتيل الطاقة.
اضطررت إلى إيقاف تشغيل شبكة wlan مرة أخرى والاتصال بـ ESP عبر 192.168.4.1 مباشرة للوصول إليها

ليس لدي أي فكرة عما حدث

kischde ما نوع نقطة الوصول التي تستخدمها؟
الليلة الماضية واجهت شيئًا مشابهًا بنفسي أثناء تجربة تثبيت AP جديد.
كنت أحاول تثبيت MikroTik AP وكان كل شيء يعمل بشكل جيد حتى احتاج ESP إلى إعادة الاتصال.
من خلال واجهة الويب الخاصة بـ MikroTik ، تمكنت من رؤية العقدة متصلة بشبكة WiFi ، لكنها لم تتلق عنوان IP.
حتى عندما حاولت توصيله بنقطة اتصال هاتفي ، كان بإمكاني إعادة تشغيل ESP لكنه كرر هذا السلوك.
فقط عندما أقوم بتعيين تكوين AP الرئيسي على نقطة وصول أخرى ، بدأت في الاتصال كما ينبغي.

لاحظ أنه لم يتم إعادة تشغيل العقدة لتحقيق ذلك.

الشيء الوحيد الذي تم تعيينه "غير صحيح" على نقطة الوصول هذه ، مقارنةً بـ MikroTik الآخر لدي ، هو أنه تم ضبط إعداد "مسافة" على "داخلي".
سأقوم بإجراء المزيد من الاختبارات لمعرفة الفرق هنا ، ولكن كما تمت مناقشته من قبل ، يبدو أنه بعض المهلة المحددة للرد على حزمة.
ويمكنني أن أتخيل أن ESP يستغرق بعض الوقت للرد على طلبات DHCP ، والتي قد تكون قصيرة جدًا لهذا الإعداد.

أنا أستخدم Swisscom AP (مزود الاتصالات السويسري AP) ، لكن كان لدي نفس المشكلات المكتوبة هنا في أماكن مختلفة مثل الأشخاص الذين يستخدمون MikroTik. لذلك ربما يحتوي على نفس مجموعة الشرائح ، لكن لا يمكنني تغيير الكثير في الإعدادات ، على سبيل المثال تلك الإعدادات الموسعة.
قبل إعادة التشغيل ، حاولت أيضًا الاتصال بهاتفي المحمول ، كما فعلت أنت ، بنفس السلوك الذي قمت به.
أنا استخدم Fix IP ، لا DHCP
لقد تحولت الآن إلى 2019_03_05 الفعلي ، وسأرى ما سيحدث ...

هل قمت مؤخرًا بتغيير إعدادات WiFi؟
على سبيل المثال ، نقطة وصول مع عنوان MAC AA: AA: AA: AA: AA في الموضع 1 من SSID AP آخر بعنوان MAC BB: BB: BB: BB: BB: BB
لقد شعرت أن هناك بعض الإعدادات المتبقية في مكان ما في المرساب الكهروستاتيكي حيث لا نقوم بتخزينها.

سأحاول أيضًا أن أرى في مستندات NonOS كيف يمكن مسحها بشكل فعال عندما نغير إعدادات WiFi.
أيضًا في الاختبارات التي أجريتها ، يبدو أنه من المفيد حقًا استخدام أكثر من 2 SSID.
سأحاول أيضًا إضافة المزيد من الحقول لهذا ، أو ربما أسمح بتخزين بعض الملفات المشفرة في SPIFFS لتخزن كمية غير محدودة تقريبًا من WiFi AP.

هل قمت مؤخرًا بتغيير إعدادات WiFi؟

لا ، لأن لدي نقطة وصول واحدة فقط ، لم يكن هذا ضروريًا في IMO

حسنا. جيد ان تعلم.
نظرًا لأنني لا أعرف حتى الآن سبب هذا ، فأنا أحاول التخلص من أكبر قدر ممكن من المجهول.
لذا فإن الشيء الوحيد الذي تحتاج إلى القيام به لجعله يعمل مرة أخرى هو إضافة إعداد wifi مرة أخرى.

لا ، حتى أقل
لقد اضطررت إلى الاتصال مباشرة بـ esp عبر 192.168.4.1 (معطل AP)
ثم قمت بفحص كل شيء ، لكنني لم أجد أي أشياء غير طبيعية ... لذلك قمت بتجربتها وإعادة تشغيل نقطة الوصول الخاصة بي ، بدلاً من إعادة تعيين ESP وتشغيلها مرة أخرى. لذلك كان علي أن أجبر IMO على عمل اتصال WLAN "عادي / آخر".
راجع للشغل أيضًا رأيته متصلاً في AP ، ولكن لم يتم تعيين عنوان IP أيضًا ، ولكنه ثابت

حسنًا ، لقد كنت ألعب بها قليلاً ، مع 5 عقد متصلة بـ MikroTik التي ألعب بها.

بمجرد تعيين "Hw. Fragmentation Threshold" (فقط "افتح" الخيار) ، لم تعد عُقد ESP قادرة على تلقي أي عنوان IP بعد الآن.
القيمة الافتراضية لهذا الإعداد هي 256. إذا قمت بتعيينها على 1600 (ستلائم وحدة الإرسال الكبرى كاملة) ، فستتلقى جميع العقد عنوان IP وتستمر في العمل.

يظهر هذا في MikroTik UI عندما تكون العقد قادرة على التواصل:

وهذا عندما لا يتمكنون من إرسال / استقبال أي بيانات (لكنهم متصلون بطبقة WiFi)

@ TD-er هل رأيت أن هناك خيارًا في نواة esp8266 الجديدة يُدعى LWIP_FEATURES والذي أعتقد أنه سينشط إعادة تجميع IP ... ربما لم يتم تحديد ذلك في جهازك؟

انظر هنا: https://github.com/esp8266/Arduino/blob/192aaa42919dc65e5532ea4b60b002c4e19ce0ec/tools/sdk/lwip2/include/lwipopts.h#L748 -L754

يتم أيضًا تعيين دعم تجزئة IP مع هذا:
https://github.com/esp8266/Arduino/blob/192aaa42919dc65e5532ea4b60b002c4e19ce0ec/tools/sdk/lwip2/include/lwipopts.h#L756 -L763

حسنًا ، لست متأكدًا من الإعدادات الافتراضية.
هل الأرقام الواردة في السطر الأول في توثيق Doxygen هي القيم الافتراضية؟

لا أعرف ... أنا أعلم أنه في Arduino IDE في ملف تعريف plattforms ، يمكنك تحديد ما إذا كنت تريد تضمينه وتعريفه أم لا ..

اعتقدت دائمًا أن أجزاء LWIP قد تم تضمينها كمكتبات مُجمَّعة مسبقًا في التوزيع الأساسي.
لذلك من الصعب التأكد من إعادة بناء LWIP باستخدام العلامات الصحيحة.

نعم ، ولكن ذلك يعتمد على أي واحد تربطك به (من board.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-الفذ | -DLWIP_OPEN_SRC -DTCP_MSS = 536 -DLWIP_FEATURES = 1 -DLWIP_IPV6 = 0 |
| v2 عرض النطاق الترددي العالي | -llwip2-1460-الفذ | -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-الفذ | -DLWIP_OPEN_SRC -DTCP_MSS = 536 -DLWIP_FEATURES = 1 -DLWIP_IPV6 = 1 |
| v2 IPv6 أعلى عرض النطاق الترددي | -llwip6-1460-الفذ | -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 |

لذا فإن جميع إصدارات الإصدار 2 تحتوي على LWIP_FEATURES=1 باستثناء الإصدارات المصنفة على أنها "بلا ميزات"

نعم ، ولكن إذا نظرت إلى كشوفات الحساب -l ، فأنت بحاجة إلى عرض المكتبات التي تحتوي على -feat في النهاية (على عكس التسمية ، فهي بديهية بعض الشيء) ...