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

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

لا أستطيع التحدث إلى MQTT لأنني لا أستخدمها.

فقط سنتان تساويان .....

إذا كنت تميل نحو الخيار 3 ، فأنا أؤيدك بالكامل. أكره رؤيتنا نتخلى عن التحسينات التي قدمتها لنا شبكة WiFi القائمة على الأحداث. قد يكون من الأسهل إرجاع Core 2_4_x / الانتقال إلى أعلى الدفق؟

من وجهة نظر المستخدم:
سأستمر في استخدام Core 2.4.1 الجديد في أسرع وقت ممكن.
يمكن للمستخدمين دائمًا استخدام الإصدارات القديمة.

لا تنسى أن core 2.4.x يعمل على إصلاح بعض المشكلات:
وميض PWM هو التاريخ (# 1156 ثابت مع النواة 2.4.0)
المسلسل مع حزمة كبيرة هي أيضا ثابتة ...
في مرحلة ما علينا أن ننتقل إلى النواة الجديدة. العودة إلى 2.3.0 تعني فقط تأجيل المشكلة. في النهاية علينا القيام بالعمل على أي حال. المرساب الكهروستاتيكي الخاص بي أفضل بالتأكيد مع 2.4.0

كما أراها ، سيحدث Core 2_4_x ولكن ربما ليس ضروريًا في الوقت الحالي. لقد اتخذنا قرارًا سيئًا عندما مضينا قدمًا في التحديث الأساسي والنهج القائم على حدث wifi في نفس الوقت. كان يجب أن نجعلها واحدة تلو الأخرى. عندما حصلنا بعد ذلك ، في نفس الوقت ، على تحديث في الإعدادات العامة ، أصبح من الصعب للغاية تحديد المشكلة. أؤيد بشدة فكرة العودة إلى 2_3_0 أثناء إصلاح استقرار wifi + إصلاح تلف الإعدادات.

بعد ذلك ، نأمل أن نطلق الإصدار 2.1.0 ثم نركز على استقرار Core 2_4_x للإصدار 2.2.0

بعد مسح الإعدادات وتحميل الإصدار من 22.04.2019. حتى الآن كل شيء يعمل. على الأقل حتى الآن :) الذاكرة الخالية فقط ليست كافية ، حتى في الوضع العادي. سنرى كيف ستستمر.

يجب أن أتفق مع @ Budman1758 و melwinek : لقد وجدت أيضًا أنه بدءًا من وحدة نظيفة ، لا توجد مشاكل على الإطلاق مع Wifi و IP الثابت والإعدادات.
تكمن المشكلة الرئيسية في حقيقة أنه من أجل الترقية ، أحتاج الآن إلى تنظيف جميع الوحدات يدويًا وإعادة تحميلها وإعادة تكوين تكوينها.

أعتقد أننا يجب ألا ننسى أننا رسميًا ما زلنا في طور الانتقال من R120 المستقر إلى المستقر 2.1.0 ولن يتم تحويل الإعدادات بين هذين الإصدارين مما يجعلك بحاجة إلى البدء من نقطة الصفر على أي حال. ما فعلناه مع تحديث core 2_4_x هو إنشاء "نقطة توقف" مرة أخرى. إذا استطعنا التعايش مع ذلك ، فهذه ليست مشكلة. أوافق على أن التثبيت النظيف مستقر حقًا (على الأقل في NORMAL ، والذي أختبره كثيرًا). و NORMAL هو الجزء الوحيد الذي سيكون في الواقع في الإصدار والاختبار والتطوير فقط في الإصدار الليلي للتطوير على أي حال.

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

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

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

@ giig1967g أتفق معك هناك. أعتقد أن هناك بعض قضايا الفساد الجارية. قد يكون السبب وراء الخلل في شبكة wifi مقابل وجود الكثير من المشكلات المتأصلة فيه.

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

سأفكر في الأمر اليوم ، ما الذي يجب أن نفعله ، لذا يرجى إضافة المزيد من الاقتراحات / الحجج :)

@ TD-er أنت على حق مع SWITCH.
معظم الناس يستخدمون فقط ON / OFF للتبديل / التتابع.
وفي هذا البرنامج المساعد هناك مؤازرة ، باهتة وربما شيء ما.
يمكن أن تكون منفصلة.

كما أنه يتعامل مع أشياء خاصة جدًا بـ MQTT و / أو Domoticz. لا ينبغي أن يكون ذلك جزءًا من البرنامج المساعد.

@ TD-er في كثير من الحالات ، سيساعدني ذلك في تجميع نفسي ، بعد إزالة المكونات الإضافية غير الضرورية ، وفي كثير من الحالات أحتاج فقط إلى SWITCH ، و FHEM Controller ، و DHT.
لكن بعد هذه المغامرات مع الإعدادات ، أخشى أن أجمع نفسي. خاصة بعد رسالتك: https://github.com/letscontrolit/ESPEasy/issues/1292

هل ألقيت نظرة ، كيف يتم تحقيق wifi في مشاريع أخرى (مثل tasmota)؟

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

إذا أمكن ، يجب أولاً تنظيف النواة من تلك الميزات النادرة الاستخدام (أو تحويلها إلى مكون إضافي) ثم تحسينها. أيضًا ، يمكن للمرء التفكير في واجهات إضافية للمكونات الإضافية ، للسماح بتبديل المزيد من الوظائف خارج النواة.

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

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

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

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

لكن إعادة التصميم هذه ستتطلب بعض الجهد.

@ TD-er ، أنت على حق ، لكنني سأجري التغييرات بخطوات صغيرة - لأن معظم الأجزاء تعمل بشكل مستقر وقد تؤدي التغييرات الكبيرة إلى تعريض هذا الاستقرار للخطر.

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

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

ومع ذلك ، فقدت العقدة من 22.04 الاتصال.
إعادة تعيين جهاز التوجيه لا يساعد.
إعادة تعيين ESP سيساعد ، لكنني بعيد جدًا.
لذا ، فإن أفضل إصدار على عقدتي هو mega-20180410.
ربما لأنه في النواة 2.3؟
ومع ذلك ، ربما يكون الحل الجيد هو العودة إلى 2.3 لبعض الوقت؟

كلا ، لقد رأيت الليلة الماضية المشكلة (في الكود وتحدث في وحداتي الخاصة).
لم تتم إعادة الاتصال العقد الخاصة بي عندما حدث خطأ "مهلة المنارة" ، وهو سبب شائع جدًا لقطع الاتصال. إنه خطأ منطقي في الكود ، لكنه كان بالفعل قد تجاوز الساعة 1:30 صباحًا ولم أرغب في إصلاحه في تلك اللحظة. من المؤكد أنه كان قد فات وقت بناء الوقت ليلا لإصلاحه ، لذلك لم يعد هذا مهمًا ؛)

ذات الصلة: # 1064

لقد قمت للتو بوميض 6 أجهزة بالإصدار الحالي ESP_Easy_mega-20180425_test_ESP8266_4096.bin.

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

لهذا السبب سأعود - بطريقة أو بأخرى - إلى إصدار wifi صالح.

ربما يجب علينا أيضًا إزالة الإصدار الحالي ، فقط لمنع الآخرين من تحميله.

أود أن أقترح الآن إنشاء إصدار جديد 04.25 على core 2.3.0 واستبدال الإصدار الحالي :)

ليس لدي سيطرة على خادم البناء.
ونسختان برقم البنية نفسه ليست فكرة جيدة أبدًا.

أعرف أن Grovkillen يمكنه إزالة بناء اليوم.

هل تعتقد أنني يجب إزالته @ TD-er؟ سيتم بناء واحد جديد غدا.

يبدو أنه أسوأ مقارنة ببناء الأمس.
لذا نعم ، قم بإزالته.

فعله

كما تم تغيير platformio.ini.
لذا مهما حدث ، فإن بناء الغد لن يكون سيئًا مثل اليوم.

أشعر بالذعر هنا. لا تقلق ، لا يزال هناك أمل.
أولاً ، لنحصل على: بيرة: أو: بيرة: الآن ،
شكرًا لك @ TD-er على المضي قدمًا بلا كلل رغم مخاوفك ، شكرًا

بعد قولي هذا ، دعني أقول هذا:

1. وفقًا لتجربتي ، لا يوجد شيء خاطئ في الإصدارات الأساسية الأحدث باستثناء 2.4.1 التي بها تسرب ذاكرة ذكي (وحل بديل).
2. الإصدارات الأقدم من الفرع الرئيسي حتى النقطة التي تم فيها اتخاذ قرار بالتخلي عن 2.0 عملت بشكل مستقر تمامًا مع تلك الإصدارات الأساسية. و بسرعة.
3. يجب علينا حقًا (التركيز على حقًا!) التركيز على الاستقرار. لا توجد ميزات جديدة لفترة من الوقت (ما لم يتم تحسين الاستقرار) أقل من ESP32 وأقل مطاردة للذاكرة ، وأقل تسريعًا أقل لكل شيء باستثناء الاستقرار. لنتظاهر بأننا نخطط للسفر إلى القمر. بصدق. هذا الشيء يحتاج إلى العمل. إنه يحتاج إلى تحمل حالات فشل البت المفردة ، وإعادة التشغيل ، وتقلبات الطاقة والضغط الحراري.
   أعني تفشل البرمجة المتسامحة. فعلت ذلك. يمكن أن يكون ممتعًا إذا قمت بلف عقلك حوله.

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

أشعر بالذعر هنا. لا تقلق ، لا يزال هناك أمل.
أولاً ، لنحصل على 🍺 أو 🍻 الآن ،
شكرًا لك @ TD-er على المضي قدمًا بلا كلل رغم مخاوفك ، شكرًا

أتفق بنسبة 100 !!!

لا أعرف ما إذا كان هذا الخطأ معروفًا بالفعل:
بعد يوم أو يومين ، يبدو أن خادم الويب لم يعد يعمل. لا يزال النشر MQTT يعمل.
أنا أستخدم الإصدار العادي من 04.22.

@ TD-er شخصيًا سأصوت لشيء جديد مثل 2.4.1 لتجربته.

1+

1+

أشعر بالذعر هنا. لا تقلق ، لا يزال هناك أمل.

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

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

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

حول باقي القضايا الرئيسية:

• استخدام الذاكرة
• استيراد / تصدير JSON للإعدادات
• إعادة تصميم استيراد MQTT
• يجب تغيير بعض المكونات الإضافية مثل P001-switch.
• ماذا تبقى.

بالنسبة لي (وربما بالنسبة لي فقط) لم يتحسن الانتقال إلى 2.4.1 أو حتى GIT Core ، كان العكس هو الصحيح. لقد جربت حوالي 20 مجموعة مختلفة من الإصدارات الأساسية و mage-commits و lwIP. كان العودة إلى 2.3.0 وخاصة lwIP 1.4 هو الطريقة الوحيدة لجعله يعمل بشكل مستقر. لكن مرة أخرى ، فقط رأيي في هذا في بيئتي الخاصة ...

ونعم ، شكرًا جزيلاً @ TD-er و Grovkillen على العمل الرائع الذي يقومون به والوقت الذي

شكرًا لكم جميعًا ، @ TD-er لخص الطريق إلى الأمام بشكل جيد.

حول باقي القضايا الرئيسية:
• استخدام الذاكرة
• استيراد / تصدير JSON من الإعدادات
• إعادة تصميم استيراد MQTT
• يجب تغيير بعض الإضافات مثل P001-switch.
• ماذا تبقى.

وسنعود إلى الإصدار 2.3.0 لإصدار الغد ونختبر ذلك لفترة من الوقت.

تستند معظم صوري ذاتية البناء إلى مراجعة أساسية. 491c9b8b (2.4.1 + x).
الشيء الوحيد الذي أراه هو عمليات إعادة التشغيل العشوائية بجهاز Sonof 4ch. إنه جزء من التحكم في البركة الخاصة بي ، لذلك لا توجد فرصة لتوصيل واجهة تسلسلية لمراقبة أفضل ، Syslog غير قابل للاستخدام إلى حد كبير ، لأن المعلومات ذات الصلة يتم بثها قبل تشغيل WIFI.

إنها قابلة للاستخدام - طالما أنك تستخدم مكتبة lwIP 'v2 Higher Bandwith'.
وإلا سترى مشاكل في تجزئة MTU مع الحزم> 512 بايت (معطلة ، مع معلومات نافذة غير مناسبة).

تعمل ESPEasy Revs (مستودعاتي)

الالتزام 3576619181926b3adff5a1a133390eb71e808ae9
الدمج: 9038bd2 d083a58
المؤلف: سوسيس سترولش
التاريخ: الجمعة 13 أبريل 17:07:30 2018 +0200

Merge remote-tracking branch 'upstream/mega' into mega

* upstream/mega:
  automaticly updated release notes for mega-20180413
  [wifi] Event based wifi, fix set AP and crash on start

و
الالتزام daf39a064d3633fe1eccfa33576fafbccd7611a7
الدمج: 2a96218 806a275
المؤلف: سوسيس سترولش
التاريخ: الإثنين أبريل 9 09:15:52 2018 +0200

Merge remote-tracking branch 'upstream/mega' into mega

* upstream/mega:
  automaticly updated release notes for mega-20180409
  Both reset/factoryreset option
  Factory Reset (not enabled yet)

يظهر أي ESPEasy بعد الجمعة 13 أبريل نتائج مروعة - التحدث غير العامل - حتى عند مسح الفلاش بالكامل قبل وميض الملف الثنائي (عبر Arduino IDE).

لذلك ، أقترح استخدام 2.4.1 (أو أحدث) وصقل ESPEasy (WIFI و config).
يبدو أن Core نفسها على ما يرام حتى الآن.

لول الجمعة 13th ، يوم سيئ الحظ بالفعل ..
إذن ما هو "البولندية ESPEasy (WIFI والتكوين)." ؟
فرع مختلف ..؟
بولندا الملقب بالبولندية أو البولندية كما هو الحال في بوف آند شاين ، هكتار

susisstrolch كيف يمكنني التقاط مثل هذه الأخطاء؟
"مشاكل في تجزئة MTU مع الحزم> 512 بايت (معطلة ، مع معلومات نافذة غير صحيحة)."

فقط أرسل طلبًا مُجهزًا لخادم ويب خاص ، مع رأس إضافي بحد أدنى 512 حرفًا

Oxyandy : تشغيل tcpdump على خادم FHEM والتحليل باستخدام WireShark ، وجدت أنه تم إرسال آخر 512 بايت من استجابة JSON 700 بايت أولاً ، متبوعًا برأس HTTP.
وهاتين الحزمتين حيث تفتقد ببساطة إلى معلومات نافذة TCP.
يمكن إرسال مزيد من التفاصيل عند الطلب ...
polish مثل كلمة Buff & shine

بالنسبة لي ، الإصدار 22.04.2018 مع Core 2.4.1 يعمل بشكل جيد.

هل يمكنك أيضًا التحقق من عملي بالأمس ، ولكن بعد ذلك مبني على 2.4.1؟
https://github.com/TD-er/ESPEasy/tree/bugfix/wifi_stability

في 2.3.0 ما زلت أواجه مشكلات مع IP ثابت.
لم تختبر بعد وضع AP مع صفحة الإعداد.

أنا فقط تومض wemos مع نسختك
[wifi] محاولة جعل شبكة wifi القائمة على الحدث أبسط).

يدير Vesion .....

ماذا يجب ان افعل الان؟

اللعنة ، من آخر اختباري (22.04.1018) ، أغلقت 4 من 8 أجهزة بعد حوالي 7 ساعات.

اعتقد لا يوجد سجل؟ :(
هل تعطلت العقد (تعليق) أم لم تعيد الاتصال؟
هل يردون على الأمر ping ، وبالتالي فقط خادم الويب معطل أو مشغول للغاية (تتطلب إعادة الاتصال MQTT الكثير من الموارد)؟

وفي الوقت نفسه شنق 5 أجهزة.
ليس لدي سجل. خادم الويب لا يمكن الوصول إليه. بينغ لا يعمل أيضا.

لقد ماتوا للتو.

يجب أن تحاول تسجيله. قد يعطينا بعض التلميحات المفيدة

أقوم بتسجيل إصدار Gijs. لقد كان يعمل لمدة 55 دقيقة الآن. :)

أوه ، يمكنني التغلب على ذلك! لدي 12 جهازًا تعمل بين 45 و 263 دقيقة على إصدار Gijs (مع esp core من GIT) 😀 وما زلت جميعًا سعيدة ...

نعم ، لقد تغير الزمن.
في الماضي ، كانت أجهزتي تعمل لأسابيع.

اليوم أنا سعيد عندما يعملون بضع ساعات. :)

لا يزال أحد أجهزتي في المنزل يعمل على التصميم الذي صنعته في 20171231 ويمتد إلى 60 يومًا من وقت التشغيل اليوم.

لذلك أنا أعرف ما تعنيه :(

ثم لنأخذ إصدار 2017123 ، ثم يمكننا التركيز على أشياء أخرى. :)

التوقيت المحلي: | 2018-04-26 17:47:23
الجهوزية: | 0 يوم 2 ساعة 27 دقيقة
تحميل: | 10٪ (LC = 9371)
مذكرة مجانية: | 10336 (9544 - sendContentBlocking)
IP: | 192.168.0.201
شبكة Wifi RSSI: | -67 ديسيبل

مرحبًا ، لماذا لا تأخذ إصدار 60 يومًا هذا ، وقم بتمييزه بـ 2.0 واكتب بعض النقاط حول المشكلات المعروفة (لا توجد ميزات مفقودة)

@ s0170071 هل نحتاج حقًا إلى منتج عامل بنسبة 75٪ ، وتم ملء الكثير من المشكلات بعد الإصدار؟

ربما ليست هناك حاجة للعودة حتى الآن ... هذا من أحدث إعادة تشغيل يدوي:

الجهوزية: 21 يوم 3 ساعات 32 دقيقة
الحمل: 32٪ (LC = 6281)
المذكرة المجانية: 14328 (13392 - parseTemplate3)

بناء | 20100 - ميجا (كور 2_3_0)
نسخة GIT | ميجا 20180308
الإضافات | 72 [عادي] [اختبار] [تطوير]
بناء Md5 | eb5a94ae675cb343cc387319fd8c4f9a
فحص Md5 | تم الاجتياز بنجاح.
بناء الوقت | 8 مارس 2018 03:05:36
اسم الملف الثنائي | البرامج الثابتة

تم تشغيل 6 أجهزة لمدة 5 ساعات - رقم قياسي جديد.

هذا أكثر من 30 ساعة بالفعل ؛)

لدي الآن تقريبًا جميع الأجهزة (+12) التي تعمل على تغييرات @ TD-er من tonigt. جميع أجهزة Wemos D1 Mini مزودة بأجهزة استشعار ومرحلات متنوعة (جميعها مختلفة). معظمهم لديهم الآن 10 ساعات + وقت تشغيل. سأقوم بوميض آخرها الآن أيضًا.
كان لدي عمليتان أو ثلاث عمليات إعادة تشغيل تلقائية من جهاز أو جهازين ، ولكن قد يكون هذا أيضًا من المكونات الإضافية أو المستشعرات المعيبة (أستخدم أيضًا بعض مكونات التطوير الإضافية وحتى غيرت التكوين لدعم 24 مهمة واستخدام esp GIT core ، بعضها حتى بدون مسح التكوين أولا). لكنهم عادوا دائمًا واتصلوا بالشبكة بنجاح!

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

لذلك كنت سأصوت لدمج @ TD-er التغييرات من الليلة واختبارها والمضي قدمًا من هناك ... لكن هذا مجرد MHO ...

وبفضل @ TD-er لإصلاح الخطأ السريع (جرب) !! بالنسبة لي عملت !!

لدي أيضًا إعادة تشغيل على جهاز واحد ، لكن تمت إعادة الاتصال على الفور.
جميع الأجهزة Wemos D1 mini.

لقد قمت بتشغيل الإصدار التجريبي هنا مع 71 ملحقًا.
يوجد على الأجهزة ما يقرب من BME280 و Pir و MH-Z19 ومستشعر الغبار وبعض المصابيح.

خادم الويب يتفاعل بسرعة كبيرة.
في الوقت الحالي أنا راضٍ جدًا عن هذا الإصدار و Core 2.4.1.

ربما هو معروف بالفعل (إذا كان الأمر كذلك ، يرجى تجاهله)
لقد قمت بتثبيت برنامج ESP pro mini مع ESP_Easy_mega-20180422_normal_ESP8266_4096.bin (core 2.4.0).
إنه يعمل منذ 3 أيام!
لا يمكن الوصول إلى واجهة المستخدم الرسومية بعد الآن ، إلا بعد بدء التشغيل البارد. (testet مع esp آخر)
Ping على ما يرام ، عمل النشر mqtt أيضًا ، تبديل GPIO عبر http يعمل أيضًا.
المشكلة "الوحيدة" ، واجهة المستخدم الرسومية لا يمكن الوصول إليها.
بمعنى آخر ، يعمل المرساب الكهروستاتيكي بشكل أعمى ، وكل شيء على ما يرام ، فقط واجهة المستخدم الرسومية لا تستجيب.
بعد كتابة عنوان IP في المتصفح ، احصل على:

ily: sans-serif ؛ حجم الخط: 12 نقطة ؛ الهامش: 0 بكسل ؛ الحشو: 0 بكسل ؛ تحجيم الصندوق: مربع الحدود ؛ } h1 {font-size: 16pt؛ اللون: # 07D ؛ الهامش: 8 بكسل 0 ؛ الخط- weig190 ؛ اللون: # 07D ؛ } .button {margin: 4px؛ الحشو: 4 بكسل 16 بكسل ؛ لون الخلفية: # 07D ؛ اللون: #FFF ؛ زخرفة النص: لا شيء ؛ نصف قطر الحدود: 4 بكسل ؛ الحدود: 190 190 ative ؛ المؤشر: المؤشر. حجم الخط: 12 نقطة ؛ -webkit-user-select: لا شيء ؛ -moz- تحديد المستخدم: لا شيء ؛ -ms-u

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

هل يمكنك أيضًا تسجيل استخدام الذاكرة؟ فقط لمعرفة ما إذا كان هناك بعض تسرب الذاكرة في 2.4.1 كما أفاد البعض.

نعم ، نفس الشيء تمامًا مع الإصدار من 22.04.2018.
الجهاز قيد التشغيل ولكن خادم الويب لا يمكن الوصول إليه.

سأحاول تسجيله.
يبدو ثابتًا.

مذكرة مجانية: | 9792 (9008 - sendContentBlocking)

هل تقصد sysheap؟

@ uzi18 لا يمكنك الحصول على كلٍّ من الطليعة والاستقرار. إصدار 60 يومًا مستقر ، أليس كذلك؟

@ TD-er إذا تركت نافذة القواعد مفتوحة لبضع دقائق ، فستختفي جميع القواعد.

هذا مع 2.3.0؟

لدي 2.4.1

مرحبا،
أقوم باختبار 20180426. يعمل ولكنه بطيء حقًا مقارنة بـ 20180424.
بالنسبة لي ، كان النواة 2.4.0 يعمل بشكل جيد ومستقر.
مع الإصدار الجديد ، استغرق MQTT أكثر من دقيقة واحدة للاتصال بينما كان الإصدار السابق نصف الوقت.
هل أنا محظوظ مع Core 2.4.0؟ أم أنها مجرد مسألة تكوين؟

أجد إصدار @ TD-er من الأمس مع Core 2.4.1 سريع للغاية.

بعد تشغيل الجهد ، يستغرق الوصول إلى واجهة الويب بضع ثوانٍ فقط.
تأتي رسائل MQTT على الفور.

فقط للمهتمين. أنا أتتبع وحدة المعالجة المركزية والذاكرة و RSSI. مرفق رسم بياني لجميع الوحدات. يمكنك أن ترى بوضوح على استخدام الذاكرة ، عندما قمت بالترقية إلى 2.4.x core. ومع ذلك ، يبدو أن الذاكرة مستقرة (على سبيل المثال ، عدم وجود تسرب) ...
الأجهزة من 1 إلى 11 و 16 "قيد الاستخدام" مع أجهزة استشعار وما إلى ذلك. أما الأجهزة الأخرى فهي مجرد أجهزة D1 عادية بدون أي شيء متصل بها.

مرحبًا micropet : كيف يمكنني استخدام إصدار الأمس مع Core 2.4.1؟

بدأت أعتقد أنه ربما يكون Wemos أكثر استقرارًا من SONOS؟
أنا أستخدم Wemos أيضًا

مع:
https://github.com/TD-er/ESPEasy/commits/bugfix/wifi_stability
وفي المنصة:
[كور_2_4_1]
المنصة = [email protected]

micropet و @ TD-er: لقد قمت للتو بتجميع فرع استقرار wifi مع النواة 2.4.1.
رائع. سريع مذهل.
سيتركه يعمل لمدة 3 أيام قادمة وتقديم تقرير مرة أخرى. يحتوي على قواعد معقدة للغاية ...
في الوقت الحالي: 7 ثوانٍ للاتصال بـ MQTT مقارنة بـ 60 مع إصدار 2.3.0 20180426.

أرى بعض عمليات إعادة الاتصال في استيراد MQTT.

104 : INIT : Free RAM:20040
104 : INIT : I2C
104 : INIT : SPI not enabled
1213 : INFO : Plugins: 72 [Normal] [Testing] [Development] (ESP82xx Core 2_4_1)
1214 : EVENT: System#Wake
1289 : WIFI : Set WiFi to STA
mode : sta(60:01:94:8e:ba:c9)
                             add if0
                                    1292 : WIFI : Connecting KeepOut attempt #0
1293 : IP   : Static IP : 192.168.1.206 GW: 192.168.1.1 SN: 255.255.255.0 DNS: 8.8.8.8
1405 : EVENT: System#Boot
1412 : ACT  : gpio,14,1
1414 : SW   : GPIO 14 Set to 1
1416 : ACT  : gpio,12,1
1417 : SW   : GPIO 12 Set to 1
1420 : ACT  : gpio,13,1
1420 : SW   : GPIO 13 Set to 1
1422 : ACT  :
1431 : ACT  : taskvalueset 1,1,1
1441 : ACT  : taskvalueset 1,2,1
1453 : ACT  : taskvalueset 1,3,1
1465 : ACT  : taskvalueset 1,4,1
1474 : ACT  :
1482 : ACT  :
1489 : ACT  : timerset,4,60
1568 : WD   : Uptime 0 ConnectFailures 0 FreeMem 18616
1682 : Dummy: value 1: 1.00
1683 : Dummy: value 2: 1.00
1683 : Dummy: value 3: 1.00
1683 : Dummy: value 4: 1.00
1684 : EVENT: Relay1#r1=1.00
1753 : EVENT: Relay1#r2=1.00
1824 : EVENT: Relay1#r3=1.00
1890 : EVENT: Relay1#r4=1.00
2251 : SYS  : 0.00
2253 : EVENT: SysInfoUptime#UptimeDays=0.00
3188 : IMPT : MQTT 037 Intentional reconnect
3562 : IMPT : MQTT 037 Intentional reconnect
scandone
        state: 0 -> 2 (b0)
                          5130 : Dummy: value 1: 25.80
5130 : Dummy: value 2: 27.20
5130 : Dummy: value 3: 27.40
5130 : Dummy: value 4: 0.00
5131 : EVENT: temp#t1=25.80
state: 2 -> 3 (0)
                 5158 : ACT  : timerset,1,2
state: 3 -> 5 (10)
                  add 0
                       aid 5
                            cnt
                                5174 : ACT  : lcd,1,20,*

connected with KeepOut, channel 9
                                 ip:192.168.1.206,mask:255.255.255.0,gw:192.168.1.1
   5239 : EVENT: temp#t2=27.20
5266 : ACT  : timerset,2,3
5276 : ACT  : lcd,1,20,*
5335 : EVENT: temp#t3=27.40
5365 : ACT  : timerset,3,4
5375 : ACT  : lcd,1,20,*
5428 : EVENT: temp#t4=0.00
5503 : Dummy: value 1: 18.00
5504 : Dummy: value 2: 11.00
5504 : Dummy: value 3: 12.00
5504 : Dummy: value 4: 0.00
5505 : EVENT: local#LSet1=18.00
5575 : EVENT: local#LSet2=11.00
5645 : EVENT: local#LSet3=12.00
5715 : EVENT: local#empty=0.00
6553 : Current Time Zone:  DST time start: 2018-03-25 02:00:00 offset: 120 minSTD time start: 2018-10-28 03:00:00 offset: 60 min
6554 : EVENT: Time#Initialized
6627 : EVENT: Clock#Time=Thu,22:59
6702 : IMPT : MQTT 037 Intentional reconnect
6964 : IMPT : Connected to MQTT broker with Client ID=ESPT6-Import
6965 : EVENT: MQTTimport#Connected
6981 : ACT  : publish /ESPT6/dummy/requestedTempUpdate,0
7059 : IMPT : [import1#Set1] subscribed to /OH2/status/nSetTemp1
7061 : IMPT : [import1#Set2] subscribed to /OH2/status/nSetTemp2
7062 : IMPT : [import1#Set3] subscribed to /OH2/status/nSetTemp3
7063 : IMPT : [import1#master] subscribed to /OH2/status/nMasterCaldaia
7065 : WIFI : Connected! AP: KeepOut (BC:EE:7B:EF:A3:38) Ch: 9 Duration: 3911 ms
7065 : EVENT: WiFi#ChangedAccesspoint
7144 : WIFI : Static IP: 192.168.1.206 (ESPT6-16) GW: 192.168.1.1 SN: 255.255.255.0   duration: 1940 ms
7173 : EVENT: Time#Set
7247 : EVENT: WiFi#Connected
7316 : Webserver: start
7332 : IMPT : MQTT 037 Intentional reconnect
7587 : IMPT : Error subscribing to /OH2/status/nSetTemp1
7588 : EVENT: Rules#Timer=1
ping 1, timeout 0, total payload 32 bytes, 1067 ms
                                                  7648 : [if 0=1]=false
7650 : else = true
7651 : ACT  : timerset,5,6
7688 : EVENT: Rules#Timer=1 Processing time:100 milliSeconds
7690 : MQTT : Intentional reconnect
7704 : MQTT : Connected to broker with client ID: ESPClient_60:01:94:8E:BA:C9
7707 : Subscribed to: /ESPT6/#
7708 : EVENT: MQTT#Connected
7722 : ACT  : publish /ESPT6/dummy/requestedTempUpdate,0
7813 : EVENT: MQTT#Connected Processing time:105 milliSeconds
7828 : IMPT : [import1#Set1] : 18.00
7828 : EVENT: import1#Set1=18.00
7882 : ACT  : taskvalueset,6,1,18
7893 : ACT  : timerset,1,2
7904 : ACT  : lcd,1,20,*
7955 : EVENT: import1#Set1=18.00 Processing time:127 milliSeconds
8065 : MQTT : Topic: /ESPT6/status/LWT
8065 : MQTT : Payload: Connected
8075 : IMPT : [import1#Set2] : 11.00
8075 : EVENT: import1#Set2=11.00
8131 : ACT  : taskvalueset,6,2,11
8143 : ACT  : timerset,2,3
8152 : ACT  : lcd,1,20,*
8199 : EVENT: import1#Set2=11.00 Processing time:124 milliSeconds
8206 : MQTT : Topic: /ESPT6/dummy/requestedTempUpdate
8207 : MQTT : Payload: 0
8218 : MQTT : Topic: /ESPT6/Relay1/r1
8218 : MQTT : Payload: 0
8219 : MQTT : Topic: /ESPT6/Relay1/r2
8219 : MQTT : Payload: 1
8220 : MQTT : Topic: /ESPT6/Relay1/r3
8220 : MQTT : Payload: 1
8220 : MQTT : Topic: /ESPT6/Relay1/r4
8220 : MQTT : Payload: 1
8221 : MQTT : Topic: /ESPT6/SysInfoUptime/UptimeDays
8221 : MQTT : Payload: 0.1
8222 : MQTT : Topic: /ESPT6/status/LWT
8222 : MQTT : Payload: Connected
8223 : MQTT : Topic: /ESPT6/dummy/requestedTempUpdate
8223 : MQTT : Payload: 0
ping 1, timeout 0, total payload 32 bytes, 1112 ms
                                                  8320 : IMPT : [import1#Set3] : 12.00
8320 : EVENT: import1#Set3=12.00
8376 : ACT  : taskvalueset,6,3,12
8387 : ACT  : timerset,3,4
8396 : ACT  : lcd,1,20,*
8441 : EVENT: import1#Set3=12.00 Processing time:121 milliSeconds
8565 : IMPT : [import1#master] : 0.00
8565 : EVENT: import1#master=0.00
8581 : ACT  : timerset,1,2
8591 : ACT  : timerset,2,3
8600 : ACT  : timerset,3,4
8608 : ACT  : lcd,1,20,*
8684 : EVENT: import1#master=0.00 Processing time:119 milliSeconds
8696 : EVENT: MQTTimport#Disconnected
8774 : EVENT: MQTTimport#Disconnected Processing time:78 milliSeconds
8775 : IMPT : MQTT 037 Connection lost
9712 : IMPT : Connected to MQTT broker with Client ID=ESPT6-Import
9713 : EVENT: MQTTimport#Connected
9725 : ACT  : publish /ESPT6/dummy/requestedTempUpdate,0
9809 : EVENT: MQTTimport#Connected Processing time:96 milliSeconds
9813 : IMPT : [import1#Set1] subscribed to /OH2/status/nSetTemp1
9813 : IMPT : [import1#Set2] subscribed to /OH2/status/nSetTemp2
9814 : IMPT : [import1#Set3] subscribed to /OH2/status/nSetTemp3
9815 : IMPT : [import1#master] subscribed to /OH2/status/nMasterCaldaia
9817 : MQTT : Topic: /ESPT6/dummy/requestedTempUpdate
9817 : MQTT : Payload: 0
9931 : IMPT : [import1#Set1] : 18.00
9931 : EVENT: import1#Set1=18.00
9985 : ACT  : taskvalueset,6,1,18
9996 : ACT  : timerset,1,2
10005 : ACT  : lcd,1,20,*
10053 : EVENT: import1#Set1=18.00 Processing time:122 milliSeconds
10173 : IMPT : [import1#Set2] : 11.00
10174 : EVENT: import1#Set2=11.00
10228 : ACT  : taskvalueset,6,2,11
10239 : ACT  : timerset,2,3
10248 : ACT  : lcd,1,20,*
10295 : EVENT: import1#Set2=11.00 Processing time:121 milliSeconds
10414 : IMPT : [import1#Set3] : 12.00
10414 : EVENT: import1#Set3=12.00
10470 : ACT  : taskvalueset,6,3,12

@ giig1967g هل هناك فرصة لإنشاء ملف bin لذلك يمكنني تنزيله؟ إصدار 4meg؟ ما زلت أتعلم عملية الترجمة ....

firmware.zip

@ giig1967g ، كما قلت - سريع للغاية ويبدو أيضًا مستقرًا.

لقد أعيد الاتصال الآن خلال 7 ساعات.

@ giig1967g لا يزال تشغيل IP الثابت يواجه بعض المشكلات مع الكود الجديد.
خاصة عند تشغيل MQTT.
يبدو أن DHCP يعمل بشكل جيد.

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

حسنًا ، لقد وجدت مشكلة في كل من 20180426 (2.3.0) و WifistabilityBranch (2.4.1).
إذا قمت بإيقاف تشغيل جهاز التوجيه ثم تشغيله مرة أخرى ، فلن تقوم الوحدة بإعادة الاتصال بشبكة Wifi على الرغم من كتابتها على المسلسل "Wifi # Connected". الوحدة تعمل (التسلسلي والقواعد جيدة) ولكن لا يوجد اتصال WiFi لذا لا توجد واجهة ويب.

@ TD- هو ، دعونا نفعل ذلك. تحياتي للملك - ربما لديه فكرة أخرى. :)
و تصبح على خير.

@ TD-er: نتمنى لك التوفيق في قضايا حياتك الحقيقية ...

البعض هنا ، إذا قمت بفصل WIFI لمدة 0.2 ثانية:

29113846: ACT: timerSet، 1،60
29115651: MQTT: انقطع الاتصال
29115652: الحدث: MQTT # غير متصل
29115689: MQTT: فشل الاتصال بالوسيط
29115690: الحدث: WiFi # غير متصل
29115706: WIFI: غير متصل! السبب: '(1) غير محدد' متصل لمدة 8h04m <-------- !!
29116189: MQTT: فشل الاتصال بالوسيط
29116939: MQTT: فشل الاتصال بالوسيط
29117860: WD: Uptime 485 ConnectFailures 6 FreeMem 16416
29117881: MQTT: فشل الاتصال بالوسيط
29117938: MQTT: فشل الاتصال بالوسيط
29119189: MQTT: فشل الاتصال بالوسيط
29120689: MQTT: فشل الاتصال بالوسيط
29120736: DS: درجة الحرارة: 19.94 (28-ff-b8-ea-b4-16-3-ed)
29120738: الحدث: DS18b20 # درجة الحرارة = 19.94
29122440: MQTT: فشل الاتصال بالوسيط
29124440: MQTT: فشل الاتصال بالوسيط
29126441: MQTT: فشل الاتصال بالوسيط
29128442: MQTT: فشل الاتصال بالوسيط

@ giig1967g
يمكنك البحث عن وظيفة لبدء / إيقاف خادم الويب وإضافة return; في السطر الأول من هذه الوظيفة.
https://github.com/TD-er/ESPEasy/blob/f9be283cb70043733fdc45575457a85244660ea8/src/WebServer.ino#L570 -L585

أعتقد أن هناك مشكلة في استدعاء وظيفة "gotIP" عند استخدام IP ثابت.
هذا أيضًا سبب عدم الاستقرار عند تشغيل MQTT + IP ثابت.

ولكن هذا على الأرجح لـ @ TD-er تافه. :)

حسنًا ، أنا لا أبحث.
أعتقد أنه من الأفضل أن تفعل ذلك غدًا.
بالإضافة إلى ذلك ، أعمل هنا مع DHCP.

يبدو لي أن الاستقرار مع أجهزتي دائمًا "أفضل" (ليس مثاليًا) مع 2.3.0 لبنية أساسية

• جرب 2.4.0 و 2.41 - هم أسوأ ...

0403 ميغا عادي - يبدو أنه يعمل وإصدارات من قبل ..
أي شخص لا يزال يعاني من مشاكل مثلي قادر على تجربة 0403 من فضلك ..
susisstrolch & @ uzi18 - شكرًا لكليهما على ردودكم .. لدي فكرة أفضل عن كيفية رؤية الاتصالات الآن - سيعمل محول wireshark & ​​usb wifi 2.4g ، ولدي الكثير من قطع الغيار
شكرا

يعمل المنجم 17 ساعة تقريبًا الآن. اتصال واحد

التحديث من الوحدات الخاصة بي (الاسم | وقت التشغيل بالدقائق | القرص الأخير. السبب | اتصال wifi بالمللي ثانية):
wemos_mini_01_sysinfo | 1220 | 200 | 6462869
wemos_mini_02_sysinfo | 1223 | 1 | 19359544
wemos_mini_03_sysinfo | 657 | 1 | 1018597
wemos_mini_04_sysinfo | 1078 | 201 | 439668
wemos_mini_05_sysinfo | 650 | 6 | 9194816
wemos_mini_06_sysinfo | 927 | 1 | 955432
wemos_mini_07_sysinfo | 1142 | 1 | 14078412
wemos_mini_08_sysinfo | 730 | 1 | 7848454
wemos_mini_09_sysinfo | 1005 | 1 | 5536489
wemos_mini_10_sysinfo | 550 | 201 | 465734
wemos_mini_11_sysinfo | 662 | 4 | 15658520
wemos_mini_12_sysinfo | 1211 | 1 | 17915701
wemos_mini_13_sysinfo | 1211 | 1 | 17896590
wemos_mini_14_sysinfo | 1210 | 1 | 17882406
wemos_mini_15_sysinfo | 753 | 1 | 58904600
wemos_mini_16_sysinfo | 1197 | 1 | 17210855

إعادة تشغيل واحدة للوحدة 10 (يمكن أن تكون مرتبطة أيضًا بالمكونات الإضافية). جميع الوحدات المزودة بوحدة تحكم DHCP و FHEM بالإضافة إلى تحديثات حالة JSON العادية (تسمى عبر HTTPMOD من fhem).
خادم الويب على كل منهم لا يزال قيد التشغيل وسريع الاستجابة. لم تستخدم ip static أو صفحة الإعداد بالرغم من ذلك.

لذلك بالنسبة لي يبدو أن هذه نسخة مستقرة نوعًا ما.

نظرًا لأنني في الغالب غير متصل بالإنترنت في الأيام الأربعة المقبلة ، سأرى الأسبوع المقبل عدد الأشخاص الذين ما زالوا على قيد الحياة

والسلام على الملك. آمل أن يكون مهتمًا بإنترنت الأشياء أيضًا 😀

@ أخرق ، ستيفان هذا الإصدار؟ https://github.com/TD-er/ESPEasy/tree/bugfix/wifi_stability
وما هو جوهر؟
هل حاولت إعادة تشغيل جهاز التوجيه؟

melwinek git الالتزام: d582cab938f041f622f2d4d8016b3d4bada55580 من الفرع الرئيسي esp8266 (حتى أحدث الالتزام في الفرع الرئيسي من التطوير الأساسي).

@ cumsy-stefan core 2.3.0 أو 2.4.0 أو 2.4.1؟

أحدث GIT الالتزام! (لذا فإن الإصدار هو 2.4.1+)

لا أستطيع أن أجد هذا الالتزام.
الأحدث هو: https://github.com/letscontrolit/ESPEasy/commit/d780f1a07fdcd4eec394a0677866c2a9778eb696
هل يمكنك توفير ارتباط؟

@ clumsy-stefan فهمت ، لقد كتبت بوابة إلى الجوهر.
ما هو الالتزام ESPEasy الذي تقوم بتجميعه؟

ESPEasy الالتزام f9be283 من https://github.com/TD-er/ESPEasy/tree/bugfix/wifi_stability فرع
esp8266 يلتزم d582cab من https://github.com/esp8266/Arduino

@ TD- إيه:

@ giig1967g
يمكنك البحث عن وظيفة لبدء / إيقاف خادم الويب وإضافة عودة ؛ في السطر الأول من هذه الوظيفة.
https://github.com/TD-er/ESPEasy/blob/f9be283cb70043733fdc45575457a85244660ea8/src/WebServer.ino#L570 -L585

أعتقد أن هناك مشكلة في استدعاء وظيفة "gotIP" عند استخدام IP ثابت.
هذا أيضًا سبب عدم الاستقرار عند تشغيل MQTT + IP ثابت.

مرحبًا ، المشكلة ليست خادم الويب ، إنها الوحدة التي تبدو متصلة بشبكة Wifi ولكنها ليست كذلك. لا يمكن ping ، لا يمكن إرسال MQTT ، إلخ.

أحدث جيثب يعمل بشكل مثالي هنا على النواة 2.4.1. لا توجد مشاكل في الاتصال ، ولا يوجد تسرب للأعضاء

mvdbro هل تستخدم جهاز esp32 أو جهاز esp8266؟

أستخدم كلاً من ESP8266 و ESP32. كلاهما يعمل بشكل جيد.

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

باهر! :ابتسامة:
أحاول Core 2.4.1 على esp8266 الخاص بي أيضًا.
Static و dhcp يعملان.
يعمل dnsserver والبوابة الأسيرة.
يعمل ntp!

Feuerreiter : هل حاولت إيقاف تشغيل جهاز التوجيه
في حالتي ، يقول السجل أنه تمت إعادة الاتصال ولكنه لم يحدث.

@ giig1967g سأحاول ذلك لاحقًا في المنزل. لقد أجريت الاختبار في سيارتي باستخدام هاتفي المحمول كنقطة اتصال. ؛-)

تضمين التغريدة

أعتقد أن المجموعة الافتراضية قد تم تحميلها على العديد من المكونات الإضافية

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

[PlatformIO] تم تحديث النواة إلى 2.4.1
1+

أعتقد أن هذا قرار جيد.
ليس لدي أي مشاكل منذ ظهر أمس.

كما نشرت في موضوع آخر:
بالنسبة لأولئك الذين يحتاجون إلى القليل من المساعدة في البناء ، فقد قمت للتو بإنشاء نسخة من التصحيح الذي كتبته منذ يومين ، ولكن الآن مع core 2.4.1:
TD-er_wifi_stability_core-2.4.1.2 تحديث

تبقى الذاكرة ثابتة إلى حد ما.
يغرق قليلاً في أول 15 دقيقة.
(لا يمكن رؤيتهم هنا)
19:05:33 ESP-206 / SYSHEAP 11536
19:08:34 ESP-206 / SYSHEAP 11536
19:11:36 ESP-206 / SYSHEAP 11536
19:14:37 ESP-206 / SYSHEAP 11536
19:17:40 ESP-206 / SYSHEAP 11536
19:20:42 ESP-206 / SYSHEAP 11536
19:23:45 ESP-206 / SYSHEAP 11536
19:26:47 ESP-206 / SYSHEAP 11536
19:29:50 ESP-206 / SYSHEAP 11536
19:32:52 ESP-206 / SYSHEAP 11536
19:35:54 ESP-206 / SYSHEAP 11536
19:38:57 ESP-206 / SYSHEAP 11536
19:41:59 ESP-206 / SYSHEAP 11536
19:45:01 ESP-206 / SYSHEAP 11536
19:48:04 ESP-206 / SYSHEAP 11536
19:51:06 ESP-206 / SYSHEAP 11536
19:54:09 ESP-206 / SYSHEAP 11536
19:57:11 ESP-206 / SYSHEAP 11536
20:00:13 ESP-206 / SYSHEAP 11536
20:03:16 ESP-206 / SYSHEAP 11536
20:06:17 ESP-206 / SYSHEAP 11536
20:09:29 ESP-206 / SYSHEAP 11656
20:12:19 ESP-206 / SYSHEAP 11592
20:15:21 ESP-206 / SYSHEAP 11592
20:18:23 ESP-206 / SYSHEAP 11592
20:21:24 ESP-206 / SYSHEAP 11592
20:24:25 ESP-206 / SYSHEAP 13192
20:27:27 ESP-206 / SYSHEAP 11592
20:30:30 ESP-206 / SYSHEAP 11592
20:33:31 ESP-206 / SYSHEAP 11592
20:36:34 ESP-206 / SYSHEAP 11592
20:39:36 ESP-206 / SYSHEAP 11592
20:42:39 ESP-206 / SYSHEAP 11592
20:45:40 ESP-206 / SYSHEAP 11592
20:48:43 ESP-206 / SYSHEAP 11592
20:51:45 ESP-206 / SYSHEAP 11592
20:54:48 ESP-206 / SYSHEAP 11592
20:57:50 ESP-206 / SYSHEAP 11592
21:00:52 ESP-206 / SYSHEAP 11592
21:03:54 ESP-206 / SYSHEAP 11592
21:06:56 ESP-206 / SYSHEAP 11424
21:09:58 ESP-206 / SYSHEAP 13024
21:13:01 ESP-206 / SYSHEAP 11424
21:16:03 ESP-206 / SYSHEAP 13024
21:19:06 ESP-206 / SYSHEAP 11424
21:22:08 ESP-206 / SYSHEAP 11448
21:25:10 ESP-206 / SYSHEAP 11424
21:28:13 ESP-206 / SYSHEAP 11424
21:31:15 ESP-206 / SYSHEAP 11424
21:34:18 ESP-206 / SYSHEAP 11424
21:37:20 ESP-206 / SYSHEAP 11424
21:40:22 ESP-206 / SYSHEAP 11424
21:43:24 ESP-206 / SYSHEAP 11424
21:46:27 ESP-206 / SYSHEAP 11424
21:49:28 ESP-206 / SYSHEAP 13024
21:52:31 ESP-206 / SYSHEAP 11424
21:55:33 ESP-206 / SYSHEAP 11424
21:58:36 ESP-206 / SYSHEAP 11424
22:01:38 ESP-206 / SYSHEAP 11424

في غضون ذلك ، تم تشغيل 8 أجهزة منذ ظهر أمس.
لم يعلق أي منهم.

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

جيد جدا أن نسمع.
دعونا نأمل أن تتمكنOxyandy أيضًا من مشاركة نتائج إيجابية مماثلة مع أحدث إصدار شاركته.
كانت العقد الخاصة به هي الأكثر أهمية عند استخدام 2.4.x

@ TD-er Morning ، وجدت أخيرًا هذا المنشور بعد إجراء اللحاق بالركب
0403 باستخدام 2.4.1 أصبح رائعًا طوال الليل ..
الآن تومض من أحدث برامجك rar العادية 1024 8266
يربط المحاولة الأولى ، تحديثات الوقت على الفور ، لا توجد أخطاء wifi (حتى الآن) ويظل متصلاً (حتى الآن) ،
خادم الويب يستجيب في كل مرة ..
بحاجة إلى مزيد من الوقت في الاختبار ، ولكن يبدو جيدًا

من الجيد سماع ذلك :)

سألقي نظرة على مشكلة NTP التي أبلغ عنها أدفع هذا الرمز إلى مستودع ESPeasy.
لنأمل الأفضل.

سيكون من الرائع حقًا أن نترك شبكة wifi على ما هي عليه ونتابع الباقي.

آمل أن تتمكن من ضبط بعض الأشياء التي أقدم ملاحظات عليها ، بمجرد أن تظهر الأشياء على أنها مستقرة مرة أخرى.
سأحاول بعض الاختبارات المحددة باستخدام مصدر wifi_stability_core-2.4.1 من Github
وربما إصلاحات ضد مشاكلي الطويلة الأمد ، إذا لم يتغير المصدر بشكل جذري

إذا كان لديك بعض الإصلاحات ، يرجى مشاركتها.

@ giig1967g لقد قمت بإجراء الاختبارات. لا توجد مشكلة في قطع الاتصال القصيرة جدًا. AP قبالة وعلى الفور. الاتصال mcunode الخاص بي إذا عادت نقطة الوصول. جهاز الكمبيوتر الخاص بي متصل بالفعل بنقطة وصول أخرى.

كما بدأت للتو في الاختبار باستخدام D1-Mini و BME280

ESPEasy: الالتزام 2abec2b0bb74018ea76203886f683761796091a2
دمج: 16d3a9f 29f89b6
المؤلف: Susis Strolch [email protected]
التاريخ: السبت 28 أبريل 10:26:14 2018 +0200

Merge remote-tracking branch 'upstream/mega' into mega

* upstream/mega:
  automaticly updated release notes for mega-20180428

النواة: الالتزام 41a64707f149d01ace37c903f448d5e3f1cee5d8
المؤلف: مارسيل ستور [email protected]
التاريخ: الخميس 26 أبريل 01:46:17 2018 +0200

Fix WiFi status formatting issue (bullet list) (#4671)

مخصص. h:
"# warning" ** استخدام إعدادات من ملف Custom.h * "

إذا تم تعريفه (ESP8266)

// تمكين تحديث Arduino OTA.
// ملاحظة: يضيف هذا حوالي 10 كيلو بايت إلى حجم البرنامج الثابت وذاكرة وصول عشوائي إضافية تبلغ 1 كيلو بايت.
// #define FEATURE_ARDUINO_OTA

// تمكين وضع mDNS (يضيف حوالي 6 كيلو بايت من ذاكرة الوصول العشوائي وبعض وحدات بايت IRAM)
// #define FEATURE_MDNS

إنهاء إذا

undef PLUGIN_BUILD_NORMAL

undef PLUGIN_BUILD_TESTING

undef PLUGIN_BUILD_DEV

حدد PLUGIN_BUILD_CUSTOM

undef BUILD_UPLOADER

إذا تم تحديده (BUILD_UPLOADER)

#warning "**** Building ESP8285 Uploader image ***"

آخر

// تحديد الإضافات الخاصة بنا
#define USES_P001 // Switch
#define USES_P002 // ADC
#define USES_P004 // دالاس
#define USES_P005 // DHT
#define USES_P013 // HCSR04
#define USES_P026 // SysInfo
#define USES_P028 // BME280
#define USES_P033 // دمية

#define USES_C008   // Generic HTTP
#define USES_C009   // FHEM HTTP
#define USES_C013   // ESPEasy P2P network

إنهاء إذا

undef BUILD_GIT

حدد BUILD_GIT "2abec2b" `

يبدو أن هناك بعض المشكلات في NTP:
"
تهيئة: إصدار التمهيد: 2abec2b (ESP82xx Core 41a64707)

80: تهيئة: التمهيد الدافئ # 2

81: ف.ش .: تصاعد ...

106: FS: تم التحميل بنجاح ، تم استخدام 76053 بايت من 957314

115: CRC: لم يتم العثور على مجموع اختباري لذاكرة البرنامج. تحقق من إخراج crc2.py

144: اتفاقية حقوق الطفل: إعدادات الأمان اتفاقية حقوق الطفل ... حسنًا

227: تهيئة: ذاكرة RAM مجانية

227: تهيئة: I2C

227: تهيئة: SPI غير ممكّن

232: معلومات: المكونات الإضافية: 8 (ESP82xx Core 41a64707)

233: الحدث: تنبيه النظام #

241: WIFI: اضبط WiFi على STA
242: WIFI: توصيل محاولة SusiconStrolch # 0
355: حدث: نظام # التمهيد
364: WD: وقت التشغيل 0 ConnectFailures 0 FreeMem 31504
3987: BMx280: تم اكتشاف BME280
5575: BME280: نقطة الندى 8.03 درجة مئوية
5576: BME280: العنوان: 0x76
5576: BME280: درجة الحرارة: 18.49
5576: BME280: الرطوبة: 50.75
5576: BME280: الضغط الجوي: 1010.58
5583: الحدث: BMx280 # درجة الحرارة = 18.49
5592: الحدث: BMx280 # الرطوبة = 50.75
5597: الحدث: BMx280 # الضغط = 1010.58
5853: المنطقة الزمنية الحالية: التوقيت الصيفي البداية: 2018-03-25 02:00:00 الإزاحة: 120 دقيقة بدء وقت STD: 2018-10-28 03:00:00 الإزاحة: 60 دقيقة
5853: الحدث: الوقت # مهيأ
5862: الحدث: الساعة # الوقت = السبت ، 10:52
5866: ACT: Taskvalueset 12،1،0
5872: ACT: مجموعة قيم المهام 12 ، 2 ، -58
5877: ACT: Taskvalueset 12،3،29912
5883: ACT: Taskvalueset 12،4،39164
5888: WIFI: متصل! AP: SusiconStrolch (38: 10: D5: B2: 22: 1E) الفصل: 13 المدة: 3783 مللي ثانية
5888: الحدث: WiFi # ChangedAccesspoint
5894: WIFI: DHCP IP: 192.168.254.71 (D1pro-01-11) GW: 192.168.254.1 SN: 255.255.255.0 المدة: 17 مللي ثانية
5913: المنطقة الزمنية الحالية: التوقيت الصيفي البداية: 2036-03-30 02:00:00 الإزاحة: 120 دقيقة بدء وقت STD: 2036-10-26 03:00:00 الإزاحة: 60 دقيقة
5914: الحدث: الوقت # ضبط
5921: الحدث: WiFi # متصل
5928: خادم الويب: ابدأ
5935: الحدث: الساعة # الوقت = الخميس ، 07:28
"
5853: المنطقة الزمنية الحالية: التوقيت الصيفي ، وقت البدء: 2018-03-25 02:00:00
5913: المنطقة الزمنية الحالية: التوقيت الصيفي البداية: 2036-03-30 02:00:00 الإزاحة: 120 دقيقة بدء وقت STD:

هذا رمز خطأ -1 معروف ولا يزال يتم تحويله إلى خطأ زمني.

حسنًا ، ما زلت أتساءل كيف قد ينتج عن الاتصال بـ NTP -1.

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

أعتقد أنه متعلق بـ UDP. لا أرى أيًا من أجهزتي الأخرى. والعكس صحيح.

susisstrolch هذا مع IP ثابت ، أو مع DHCP؟

@ TD-er patching على أساس BUILD_GIT فكرة سيئة لأنها تتغير على الشوكات والفروع والالتزامات المحلية.
يجب أن يكون هناك نوع / متغير مختلف - قد يكون BUILD_FEATURE - الذي يتحكم في مثل هذا السلوك.

نظرًا لأنني لم أعد تشغيل نقطة الوصول الخاصة بي تقريبًا ، فقد مر دون أن يلاحظها أحد فشل إعادة الاتصال بأحدث مصدر جيثب (20180428). حاولت الحصول على بعض الوضع الداخلي لمعرفة ما يحدث:

بعد التمهيد:
الاتصال بـ Wifi.status (): 3 تعني WL_CONNECTED
حالة wifi المتغيرة: 3 تعني ESPEASY_WIFI_SERVICES_INITIALIZED

بعد إعادة تشغيل AP
الاتصال بـ Wifi.status (): 3 تعني WL_CONNECTED
حالة wifi المتغيرة: 0 تعني ESPEASY_WIFI_DISCONNECTED

هذا لا يتغير بمرور الوقت ولا يعيد ESP الاتصال أبدًا

فقط أتساءل لماذا لا تزال مكالمة Wifi.status () إلى النواة تبلغ عن الحالة 3 (WL_CONNECTED)
هل هذا لأن شبكة wifi القائمة على الحدث تتداخل مع الحالة الأساسية الداخلية؟

السلوك هو نفسه في النواة 2_3_0 و 2_4_1

هذا مع DHCP

وأتوقع بعد إعادة التشغيل العادي:

الاتصال بـ Wifi.status (): 3 تعني WL_CONNECTED
حالة wifi المتغيرة: 1 تعني ESPEASY_WIFI_CONNECTED

بدلا من:
الاتصال بـ Wifi.status (): 3 تعني WL_CONNECTED
حالة wifi المتغيرة: 3 تعني ESPEASY_WIFI_SERVICES_INITIALIZED

حسنًا ، هذا سؤال جيدmvdbro
ربما لم يتم تحديث الحالة WL_CONNECTED مطلقًا لأنها لا تستدعي الوظيفة لتحديث هذه الحالة.
فقط من الذاكرة ، أود أن أقول أن هذه الوظيفة تسمى في المكتبة الأساسية عندما يتم التعامل مع الحدث "got IP".
سأبحث في هذا المجال من رمز المكتبة الأساسي.
شكرا لملاحظتك.

susisstrolch حسنًا ، سأحاول أيضًا مع DHCP هنا.
يمكن لوحدات الاختبار الخاصة بي رؤية بعضها البعض عبر اتصال ESPeasy UDP الداخلي ، لكنها تعمل حاليًا على IP ثابت ، نظرًا لأن ذلك أعطى معظم المشكلات مؤخرًا.

@ TD-er Hold on - سوف نتحقق مما إذا كانت مشكلة أساسية ذات صلة.

تضمين التغريدة
ها هو الكود:
https://github.com/esp8266/Arduino/blob/836c7da8cc1ad11a66e0be1f30d35a92b5317bcc/libraries/ESP8266WiFi/src/ESP8266WiFiSTA.cpp#L497 -L513

في الواقع ، طالما لم يتم تعيين الحالة الداخلية على "حصلت على IP" ، فلن يتم إرجاع WL_CONNECTED.

حول الاختلاف في أسماء المتغيرات بين التعداد / المعرفة في ESPeasy والمكتبة الأساسية.
لا تعكس حالات المكتبة الأساسية الحالة الحقيقية حقًا ، حيث يمكنك الاتصال وليس لديك عنوان IP.

قد يكون من الأفضل الاحتفاظ بهذا الموضوع لمشكلات الاتصال / إعادة الاتصال بشبكة Wifi فقط حتى يمكن إصلاح ذلك في المقام الأول.

أعتقد أن هذه هي الرموز الفعالة المستخدمة:

رموز حالة Wifi.status ():
WL_IDLE_STATUS 0
WL_NO_SSID_AVAIL 1
WL_SCAN_COMPLETED 2
WL_CONNECTED 3
WL_CONNECT_FAILED 4
WL_CONNECTION_LOST 5
WL_ مفصول 6

رموز الحالة:
ESPEASY_WIFI_DISCONNECTED 0
ESPEASY_WIFI_CONNECTED 1
ESPEASY_WIFI_GOT_IP 2
ESPEASY_WIFI_SERVICES_INITIALIZED 3

أعتقد أنه قد يكون مرتبطًا بمشكلة اتصال / إعادة الاتصال بشبكة wifi.
مع IP الثابت ، ببساطة لا يوجد حدث لـ "got IP" ، لذلك قد يكون معالجته الحالية غير مكتملة ، مما يتسبب في بعض هذه المشكلات.

حتى بعد إعادة تشغيل AP
الاتصال بـ Wifi.status (): 3 تعني WL_CONNECTED
هذا غير صحيح.

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

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

الحل: تحقق من إدخال منفذ UDP. (65500) منجم ذهب للتو. إعادة تشغيل أخرى وكان يعمل.
يجب أن نذهب حقًا إلى التكوين المستند إلى JSON !!!

mvdbro لقد وجدت هذا للتو ، انظر أعلى الصفحة 39:
https://www.espressif.com/sites/default/files/documentation/2c-esp8266_non_os_sdk_api_reference_en.pdf
لذلك سأختبر الآن لمعرفة ما إذا كان يتعين علينا تعيين تكوين IP (مرة أخرى) بعد معالجة حدث الاتصال.

هل يمكن لشخص ما اختبار الكود في هذا العلاقات العامة: https://github.com/letscontrolit/ESPEasy/pull/1328

@ s0170071 - تم التأكيد - تم تغيير إعداد منفذ UDP.

@ TD-er حول # 1328:

INIT : Booting version: 62e6317 (ESP82xx Core 41a64707)
75 : INIT : Warm boot #1
76 : FS   : Mounting...
101 : FS   : Mount successful, used 76053 bytes of 957314
111 : CRC  : No program memory checksum found. Check output of crc2.py
142 : CRC  : SecuritySettings CRC   ...OK 
248 : INIT : Free RAM:31624
248 : INIT : I2C
248 : INIT : SPI not enabled
253 : INFO : Plugins: 8 (ESP82xx Core 41a64707)
254 : EVENT: System#Wake
261 : WIFI : Set WiFi to STA
        mode : sta(5c:cf:7f:f1:bb:e1)
        add if0
264 : WIFI : Connecting SusiconStrolch attempt #0
267 : OTA  : Arduino OTA enabled on port 8266
379 : EVENT: System#Boot
390 : WD   : Uptime 0 ConnectFailures 0 FreeMem 30112
        scandone
        state: 0 -> 2 (b0)
4014 : BMx280 : Detected BME280
        state: 2 -> 3 (0)
        state: 3 -> 5 (10)
        add 0
        aid 3
        cnt 
        connected with SusiconStrolch, channel 13
        dhcp client start...
        ip:192.168.254.71,mask:255.255.255.0,gw:192.168.254.1
5602 : BME280: dew point 8.12C
5603 : BME280 : Address: 0x76
5603 : BME280 : Temperature: 20.25
5603 : BME280 : Humidity: 45.75
5603 : BME280 : Barometric Pressure: 1010.14
5611 : EVENT: BMx280#Temperature=20.25
5620 : EVENT: BMx280#Humidity=45.75
5626 : EVENT: BMx280#Pressure=1010.14
5884 : Current Time Zone:  DST time start: 2018-03-25 02:00:00 offset: 120 minSTD time start: 2018-10-28 03:00:00 offset: 60 min
5884 : EVENT: Time#Initialized
5893 : EVENT: Clock#Time=Sat,16:10
5898 : ACT  : taskvalueset 12,1,0
5903 : ACT  : taskvalueset 12,2,-60
5908 : ACT  : taskvalueset 12,3,28376
5914 : ACT  : taskvalueset 12,4,58217
5921 : WIFI : Connected! AP: SusiconStrolch (38:10:D5:B2:22:1E) Ch: 13 Duration: 3788 ms
5921 : EVENT: WiFi#ChangedAccesspoint
5927 : IP   : Static IP : 192.168.254.71 GW: 192.168.254.1 SN: 255.255.255.0 DNS: 192.168.254.1
        STUB: dhcp_stop
5932 : WIFI : Static IP: 192.168.254.71 (D1pro-01-11) GW: 192.168.254.1 SN: 255.255.255.0   duration: 1879 ms
5957 : Current Time Zone:  DST time start: 2036-03-30 02:00:00 offset: 120 minSTD time start: 2036-10-26 03:00:00 offset: 60 min
5957 : EVENT: Time#Set
5964 : EVENT: WiFi#Connected
5971 : Webserver: start
5979 : EVENT: Clock#Time=Thu,07:28
5989 : ACT  : taskvalueset 12,1,0
5999 : ACT  : taskvalueset 12,2,-59
6006 : ACT  : taskvalueset 12,3,26040
6014 : ACT  : taskvalueset 12,4,26896
6019 : EVENT: Clock#Time=Thu,07:28 Processing time:40 milliSeconds
        ping 1, timeout 0, total payload 32 bytes, 1064 ms
        ping 1, timeout 0, total payload 32 bytes, 1065 ms
7269 : UDP  : 5C:CF:7F:23:CB:63,192.168.254.97,7
8088 : UDP  : 5C:CF:7F:1C:0B:DD,192.168.254.94,4
8396 : UDP  : 5C:CF:7F:1B:E4:F7,192.168.254.92,2
11998 : Dummy: value 1: 0.00
12000 : Dummy: value 2: -59.00
12000 : Dummy: value 3: 26040.00
12001 : Dummy: value 4: 26896.00
12006 : EVENT: sysinfo#uptime=0.00
12015 : EVENT: sysinfo#uptime=0.00 Processing time:9 milliSeconds
12016 : EVENT: sysinfo#RSSI=-59.00
12025 : EVENT: sysinfo#RSSI=-59.00 Processing time:8 milliSeconds
12025 : EVENT: sysinfo#sysheap=26040.00
12034 : EVENT: sysinfo#sysheap=26040.00 Processing time:9 milliSeconds
12034 : EVENT: sysinfo#syssec_d=26896.00
12043 : EVENT: sysinfo#syssec_d=26896.00 Processing time:9 milliSeconds
12068 : HTTP : connecting to 192.168.254.27:8383
12275 : HTTP : closing connection
        pm open,type:2 0
14437 : UDP  : 5C:CF:7F:9E:CB:D4,192.168.254.99,9
18430 : UDP  : 5C:CF:7F:1B:E9:2F,192.168.254.91,1
18533 : UDP  : 5C:CF:7F:23:C5:5A,192.168.254.96,6
25189 : UDP  : 60:01:94:83:B1:70,192.168.254.80,10
30390 : WD   : Uptime 1 ConnectFailures 0 FreeMem 24816
30391 : UDP  : Send Sysinfo message
34917 : UDP  : 5C:CF:7F:9E:CC:3D,192.168.254.98,8
37273 : UDP  : 5C:CF:7F:23:CB:63,192.168.254.97,7
38092 : UDP  : 5C:CF:7F:1C:0B:DD,192.168.254.94,4
38501 : UDP  : 5C:CF:7F:1B:E4:F7,192.168.254.92,2
44441 : UDP  : 5C:CF:7F:9E:CB:D4,192.168.254.99,9
48436 : UDP  : 5C:CF:7F:1B:E9:2F,192.168.254.91,1
48641 : UDP  : 5C:CF:7F:23:C5:5A,192.168.254.96,6
49979 : EVENT: Clock#Time=Thu,07:29
49987 : ACT  : taskvalueset 12,1,1
49994 : ACT  : taskvalueset 12,2,-57
50001 : ACT  : taskvalueset 12,3,25544
50009 : ACT  : taskvalueset 12,4,26940
50014 : EVENT: Clock#Time=Thu,07:29 Processing time:35 milliSeconds
55193 : UDP  : 60:01:94:83:B1:70,192.168.254.80,10
60390 : WD   : Uptime 1 ConnectFailures 0 FreeMem 24816
60392 : UDP  : Send Sysinfo message
64922 : UDP  : 5C:CF:7F:9E:CC:3D,192.168.254.98,8
66569 : BME280: dew point 8.10C
66571 : BME280 : Address: 0x76
66572 : BME280 : Temperature: 20.28
66572 : BME280 : Humidity: 45.58
66573 : BME280 : Barometric Pressure: 1010.10
66576 : EVENT: BMx280#Temperature=20.28
66587 : EVENT: BMx280#Temperature=20.28 Processing time:11 milliSeconds
66588 : EVENT: BMx280#Humidity=45.58
66594 : EVENT: BMx280#Humidity=45.58 Processing time:6 milliSeconds
66595 : EVENT: BMx280#Pressure=1010.10
66602 : EVENT: BMx280#Pressure=1010.10 Processing time:7 milliSeconds
66627 : HTTP : connecting to 192.168.254.27:8383
66833 : HTTP : closing connection
67277 : UDP  : 5C:CF:7F:23:CB:63,192.168.254.97,7
68096 : UDP  : 5C:CF:7F:1C:0B:DD,192.168.254.94,4
68403 : UDP  : 5C:CF:7F:1B:E4:F7,192.168.254.92,2
72860 : Dummy: value 1: 1.00
72861 : Dummy: value 2: -57.00
72862 : Dummy: value 3: 25544.00
72863 : Dummy: value 4: 26940.00
72865 : EVENT: sysinfo#uptime=1.00
72872 : EVENT: sysinfo#uptime=1.00 Processing time:7 milliSeconds
72872 : EVENT: sysinfo#RSSI=-57.00
72878 : EVENT: sysinfo#RSSI=-57.00 Processing time:6 milliSeconds
72879 : EVENT: sysinfo#sysheap=25544.00
72887 : EVENT: sysinfo#sysheap=25544.00 Processing time:8 milliSeconds
72888 : EVENT: sysinfo#syssec_d=26940.00
72897 : EVENT: sysinfo#syssec_d=26940.00 Processing time:9 milliSeconds
72924 : HTTP : connecting to 192.168.254.27:8383
73129 : HTTP : closing connection
74446 : UDP  : 5C:CF:7F:9E:CB:D4,192.168.254.99,9
78747 : UDP  : 5C:CF:7F:23:C5:5A,192.168.254.96,6
78950 : UDP  : 5C:CF:7F:1B:E9:2F,192.168.254.91,1
85197 : UDP  : 60:01:94:83:B1:70,192.168.254.80,10
90390 : WD   : Uptime 2 ConnectFailures 0 FreeMem 24816
90391 : UDP  : Send Sysinfo message
94925 : UDP  : 5C:CF:7F:9E:CC:3D,192.168.254.98,8
97280 : UDP  : 5C:CF:7F:23:CB:63,192.168.254.97,7
98101 : UDP  : 5C:CF:7F:1C:0B:DD,192.168.254.94,4
98407 : UDP  : 5C:CF:7F:1B:E4:F7,192.168.254.92,2
104448 : UDP  : 5C:CF:7F:9E:CB:D4,192.168.254.99,9
108852 : UDP  : 5C:CF:7F:23:C5:5A,192.168.254.96,6
108954 : UDP  : 5C:CF:7F:1B:E9:2F,192.168.254.91,1
110842 : EVENT: Clock#Time=Thu,07:30
110849 : ACT  : taskvalueset 12,1,2
110856 : ACT  : taskvalueset 12,2,-54
110864 : ACT  : taskvalueset 12,3,24504
110871 : ACT  : taskvalueset 12,4,27000
110876 : EVENT: Clock#Time=Thu,07:30 Processing time:34 milliSeconds

كما ترى بدأ DHCP حتى عند ضبطه على IP ثابت ...

وهنا JSON الخاص بي

{"System":{
"Build":20102,
"Git Build":"62e6317",
"Local time":"2036-02-07 07:33:33",
"Unit":11,
"Name":"D1pro-01",
"Uptime":5,
"Load":1,
"Load LC":10747,
"Free RAM":25280
},
"WiFi":{
"Hostname":"D1pro-01-11",
"IP":"192.168.254.71",
"Subnet Mask":"255.255.255.0",
"Gateway IP":"192.168.254.1",
"MAC address":"5C:CF:7F:F1:BB:E1",
"DNS 1":"192.168.254.1",
"DNS 2":"0.0.0.0",
"SSID":"SusiconStrolch",
"BSSID":"38:10:D5:B2:22:1E",
"Channel":13,
"Connected msec":319382,
"Last Disconnect Reason":1,
"Last Disconnect Reason str":"(1) Unspecified",
"RSSI":-59
},
"Sensors":[
{
"TaskNumber":4,
"Type":"Environment - BMx280",
"TaskName":"BMx280",
"TaskValues": [
{"ValueNumber":1,
"Name":"Temperature",
"Value":20.31},
{"ValueNumber":2,
"Name":"Humidity",
"Value":44.70},
{"ValueNumber":3,
"Name":"Pressure",
"Value":1010.10}]
},
{
"TaskNumber":12,
"Type":"Generic - Dummy Device",
"TaskName":"sysinfo",
"TaskValues": [
{"ValueNumber":1,
"Name":"uptime",
"Value":5},
{"ValueNumber":2,
"Name":"RSSI",
"Value":-60},
{"ValueNumber":3,
"Name":"sysheap",
"Value":25464},
{"ValueNumber":4,
"Name":"syssec_d",
"Value":27180}]
}
]
}

99: CRC: لم يتم العثور على مجموع اختباري لذاكرة البرنامج. تحقق من إخراج crc2.py
130: اتفاقية حقوق الطفل: إعدادات الأمان اتفاقية حقوق الطفل ... حسنًا
211: تهيئة: ذاكرة RAM مجانية
211: بداية: I2C
211: تهيئة: SPI غير ممكّن
1042: INFO: Plugins: 71 [عادي] [اختبار] (ESP82xx Core 2_4_1)
1042: حدث: استيقظ النظام #
1089: WIFI: اضبط WiFi على STA
1091: WIFI: توصيل محاولة SMC # 0
1103: الحدث: نظام # التمهيد
1111: ACT: انشر ESP-201 / IP، 0.0.0.0
1124: ACT: timerSet، 1،60
1152: WD: وقت التشغيل 0 ConnectFailures 0 FreeMem 20160
1183: DS: درجة الحرارة: 20.37 (28-ff-b8-ea-b4-16-3-ed)
1184: الحدث: DS18b20 # درجة الحرارة = 20.37
4887: WIFI: متصل! AP: SMC (78: 8A: 20: D1: 9B: D9) Ch: 1 المدة: 3795 مللي ثانية
4888: الحدث: WiFi # ChangedAccesspoint
4910: IP: Static IP: 192.168.0.201 GW: 192.168.0.3 SN: 255.255.255.0 DNS: 192.168.0.3
4911: WIFI: IP ثابت: 192.168.0.201 (ESP-201-1) GW: 192.168.0.3 SN: 255.255.255.0 المدة: 25 مللي ثانية
5009: المنطقة الزمنية الحالية: التوقيت الصيفي البداية: 2018-03-25 02:00:00 الإزاحة: 120 دقيقة بدء وقت STD: 2018-10-28 03:00:00 الإزاحة: 60 دقيقة
5010: الحدث: الوقت # مهيأ
5027: حدث: WiFi # متصل
5044: خادم الويب: ابدأ
5127: MQTT: إعادة الاتصال المتعمد
5182: MQTT: متصل بالوسيط بمعرف العميل: ESPClient_5C: CF: 7F: 0B: 68: 52
5184: مشترك في: ESP-201 / #
5185: حدث: MQTT # متصل
5846: الحدث: الساعة # الوقت = السبت ، 16:19

susisstrolch هذا غريب حول بدء DHCP ، لأنني كتبت تصحيحًا له مؤخرًا.
ربما تغير شيء ما في 2.4.1؟

ماذا فعلت للحصول على معلومات تصحيح الأخطاء الإضافية؟

لقد قمت ببساطة بتعيين مستوى التصحيح على "تصحيح المزيد" ...

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

تعديل:
وجدت ذلك ، يسمى Serial.setDebugOutput من الإعداد (). لذلك كانت إعادة التشغيل البسيطة كافية :)

هنا تفاعل SYSHEAP و Uptime.

لدي فضول كيف سيبدو الرسم البياني sysheap بعد يوم أو يومين.

إذا لم يفشل فسنراه. :)

تبدو المخططات جميعها مختلفة: هذا هو الجهاز الذي يحتوي على آخر تغيير وعنوان IP ثابت.

ما هو إصدار الرسم البياني السابق؟

الرسم البياني الأول النسخة الخاصة منك ليلة أمس. مع DHCP

مثير للاهتمام.
سأضيف بعض تسجيل sysheap إلى العقد الخاصة بي أيضًا.

أقوم بتسجيل الدخول مع openHAB. إنه رائع أيضًا مع Grafana.

هل يجب أن أقوم بعمل فلاش لالتزاماتك الحالية؟ ثم ضاع الرسم البياني الخاص بي على ESP-201.

أعتقد أن اختبارات استقرار wifi أكثر أهمية في الوقت الحالي.

طيب سأفعل.

حسنًا ، متصل.

تهيئة: إصدار التمهيد: (ESP82xx Core 2_4_1)
92: تهيئة: التمهيد الدافئ # 2
94: خ م: تركيب ...
118: FS: تم التحميل بنجاح ، تم استخدام 76806 بايت من 957314
131: CRC: لم يتم العثور على مجموع اختباري لذاكرة البرنامج. تحقق من إخراج crc2.py
162: اتفاقية حقوق الطفل: إعدادات الأمان اتفاقية حقوق الطفل ... حسنًا
243: تهيئة: ذاكرة وصول : 20984
243: تهيئة: I2C
243: تهيئة: SPI غير ممكّن
1073: معلومات: المكونات الإضافية: 71 [عادي] [اختبار] (ESP82xx Core 2_4_1)
1073: الحدث: النظام # تنبيه
1120: WIFI: اضبط WiFi على STA
1152: WIFI: توصيل محاولة SMC # 0
1153: IP: Static IP: 192.168.0.201 GW: 192.168.0.3 SN: 255.255.255.0 DNS: 192.168.0.3
1155: WIFI: تختلف حالة محطة SDK عن حالة Arduino. حالة SDK: 1 حالة Arduino: 6
1172: حدث: نظام # التمهيد
1178: ACT: NeoPixelAll ، 0،0،0،0
1189: ACT: انشر ESP-201 / IP، 192.168.0.201
1201: ACT: timerSet، 1،60
1226: WD: وقت التشغيل 0 ConnectFailures 0 FreeMem 20088
1257: DS: درجة الحرارة: 20.25 (28-ff-b8-ea-b4-16-3-ed)
1259: الحدث: DS18b20 # درجة الحرارة = 20.25
4952: WIFI: متصل! AP: SMC (78: 8A: 20: D1: 9B: D9) Ch: 1 المدة: 3798 مللي ثانية
4953: الحدث: WiFi # ChangedAccesspoint
4974: IP: Static IP: 192.168.0.201 GW: 192.168.0.3 SN: 255.255.255.0 DNS: 192.168.0.3
4975: WIFI: تختلف حالة محطة SDK عن حالة Arduino. حالة SDK: 5 حالة Arduino: 3
4980: WIFI: IP ثابت: 192.168.0.201 (ESP-201-1) GW: 192.168.0.3 SN: 255.255.255.0 المدة: 24 مللي ثانية
5102: المنطقة الزمنية الحالية: التوقيت الصيفي البداية: 2018-03-25 02:00:00 الإزاحة: 120 دقيقة بدء وقت STD: 2018-10-28 03:00:00 الإزاحة: 60 دقيقة
5103: الحدث: الوقت # مهيأ
5123: الحدث: WiFi # متصل
5140: خادم الويب: ابدأ
5141: WIFI: تختلف حالة محطة SDK عن حالة Arduino. حالة SDK: 5 حالة Arduino: 3
5223: MQTT: إعادة الاتصال المتعمد
5261: MQTT: متصل بالوسيط بمعرف العميل: ESPClient_5C: CF: 7F: 0B: 68: 52
5264: مشترك في: ESP-201 / #
5265: حدث: MQTT # متصل
5912: الحدث: الساعة # الوقت = الشمس ، 00:14
31226: WD: Uptime 1 ConnectFailures 0 FreeMem 15968

قمت أيضًا بتوسيع المعلومات الموجودة على صفحة sysinfo.
تمت إضافة عداد إعادة الاتصال واستخدام إعداد Static / DHCP (وإصدار SDK)

تم أيضًا تضمين بعض عمليات التحقق من إعادة الاتصال القسري ، والتي ستتم إعادة الاتصال عندما لا يكون متصلاً لفترة من الوقت.

هل يجب علي مقاطعة WIFI لمدة 0.2 ثانية؟

يرجى محاولة تحطيمه :)

موافق

244302: ACT: انشر ESP-201 / IP، 192.168.0.201
244318: ACT: نشر ESP-201 / MAC، 5C: CF: 7F: 0B: 68: 52
244331: ACT: انشر ESP-201 / الوقت ، 00:18:18
244343: ACT: نشر ESP-201 / وقت التشغيل ، 4
244355: ACT: انشر ESP-201 / RSSI، -62
244367: ACT: انشر ESP-201 / SSID، SMC
244379: ACT: نشر ESP-201 / BSSID، 78: 8A: 20: D1: 9B: D9
244391: ACT: انشر ESP-201 / CH، 1
244406: ACT: انشر ESP-201 / SYSHEAP، 12616
244422: ACT: timerSet، 1،60
255542: الحدث: WiFi # غير متصل
255560: WIFI: غير متصل! السبب: "(1) غير محدد" متصل لمدة 4 م 10 ث
255560: WIFI: تختلف حالة محطة SDK عن حالة Arduino. حالة SDK: 5 حالة Arduino: 3
255571: MQTT: انقطع الاتصال
255572: الحدث: MQTT # غير متصل
255610: MQTT: فشل الاتصال بالوسيط
256110: MQTT: فشل الاتصال بالوسيط
256860: MQTT: فشل الاتصال بالوسيط
257860: MQTT: فشل الاتصال بالوسيط
259110: MQTT: فشل الاتصال بالوسيط
260610: MQTT: فشل الاتصال بالوسيط
262360: MQTT: فشل الاتصال بالوسيط
264360: MQTT: فشل الاتصال بالوسيط
266360: MQTT: فشل الاتصال بالوسيط
268360: MQTT: فشل الاتصال بالوسيط
270360: MQTT: فشل الاتصال بالوسيط
271226: WD: Uptime 5 ConnectFailures 22 FreeMem 17224
271247: MQTT: فشل الاتصال بالوسيط
272360: MQTT: فشل الاتصال بالوسيط
274360: MQTT: فشل الاتصال بالوسيط
276360: MQTT: فشل الاتصال بالوسيط
278360: MQTT: فشل الاتصال بالوسيط
280360: MQTT: فشل الاتصال بالوسيط
282360: MQTT: فشل الاتصال بالوسيط
284360: MQTT: فشل الاتصال بالوسيط
286291: الحدث: الساعة # الوقت = الشمس ، 00:19
286359: MQTT: فشل الاتصال بالوسيط
288360: MQTT: فشل الاتصال بالوسيط
290360: MQTT: فشل الاتصال بالوسيط

فقط لهذا الفحص ، هل يمكنك تركه في هذه الحالة لمدة 4 دقائق؟
سأقوم بتقليل الفاصل الزمني لمؤشر الأسهم لهذا الفحص (حاليًا 240 ثانية)

حسنا موافق.

240 ثانية طويلة جدا

نعم أعلم ، سوف أغيره.
أخذت الفكرة للتو من هذه المشكلة: https://github.com/esp8266/Arduino/issues/4445

لا شيئ....

432148: MQTT: فشل الاتصال بالوسيط
434148: MQTT: فشل الاتصال بالوسيط
436148: MQTT: فشل الاتصال بالوسيط
438147: MQTT: فشل الاتصال بالوسيط
440148: MQTT: فشل الاتصال بالوسيط
442147: MQTT: فشل الاتصال بالوسيط
444148: MQTT: فشل الاتصال بالوسيط
446148: MQTT: فشل الاتصال بالوسيط
448148: MQTT: فشل الاتصال بالوسيط
450147: MQTT: فشل الاتصال بالوسيط
451222: WD: فشل اتصال Uptime 8 446 FreeMem 17384
451243: MQTT: فشل الاتصال بالوسيط
452148: MQTT: فشل الاتصال بالوسيط
453907: الحدث: الساعة # الوقت = الشمس ، 00:29
454148: MQTT: فشل الاتصال بالوسيط
456148: MQTT: فشل الاتصال بالوسيط
458148: MQTT: فشل الاتصال بالوسيط

انا ذاهب للنوم ، اراك غدا.

وجدت للتو مشكلة أخرى ، ربما تتعلق بـ UDP:
في وحدة إعادة ضبط المصنع الجديدة العادية ، استخدم الأوامر التسلسلية
ل wifikey
الزوجة
حفظ

إعادة التشغيل ، ثم انتقل إلى الإعدادات المتقدمة وتحقق من ssdp. اعادة التشغيل.
ينتقل إلى حلقة التمهيد ثم:

 ets Jan  8 2013,rst cause:2, boot mode:(3,7)

load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
v41a64707
~ld
⸮U87 : 


INIT : Booting version: (custom) (ESP82xx Core 41a64707)
88 : INIT : Warm boot #741
89 : FS   : Mounting...
114 : FS   : Mount successful, used 75802 bytes of 957314
120 : CRC  : No program memory checksum found. Check output of crc2.py
152 : CRC  : SecuritySettings CRC   ...OK 
258 : INIT : Free RAM:27288
258 : INIT : I2C
258 : INIT : SPI not enabled
272 : INFO : Plugins: 49 [Normal] (ESP82xx Core 41a64707)
273 : WIFI : Set WiFi to STA
304 : WIFI : Connecting MNET attempt #0
306 : WIFI  : SDK station status differs from Arduino status. SDK-status: 1 Arduino status: 6
311 : WD   : Uptime 0 ConnectFailures 0 FreeMem 26448

Exception (28):
epc1=0x40208931 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000004 depc=0x00000000

Decoding 14 results
0x40208931: UdpContext::next() at /home/john/Arduino/scetchbooks/ESPEasy/_P030_BMP280.ino line 390
0x40249cf8: HardwareSerial::write(unsigned char const*, unsigned int) at /home/john/ArduinoPortable/arduino-1.8.5_ESPgit/hardware/esp8266com/esp8266/cores/esp8266/HardwareSerial.cpp line 69
0x4024a055: Print::write(char const*) at /home/john/ArduinoPortable/arduino-1.8.5_ESPgit/hardware/esp8266com/esp8266/cores/esp8266/Print.cpp line 220
0x4024a2f1: Print::printNumber(unsigned long, unsigned char) at /home/john/ArduinoPortable/arduino-1.8.5_ESPgit/hardware/esp8266com/esp8266/cores/esp8266/Print.cpp line 220
0x4024ac4f: String::changeBuffer(unsigned int) at /home/john/ArduinoPortable/arduino-1.8.5_ESPgit/hardware/esp8266com/esp8266/cores/esp8266/WString.cpp line 714
0x40249cf8: HardwareSerial::write(unsigned char const*, unsigned int) at /home/john/ArduinoPortable/arduino-1.8.5_ESPgit/hardware/esp8266com/esp8266/cores/esp8266/HardwareSerial.cpp line 69
0x401071a2: millis at /home/john/ArduinoPortable/arduino-1.8.5_ESPgit/hardware/esp8266com/esp8266/cores/esp8266/core_esp8266_wiring.c line 183
0x4024a27c: Print::println(char const*) at /home/john/ArduinoPortable/arduino-1.8.5_ESPgit/hardware/esp8266com/esp8266/cores/esp8266/Print.cpp line 220
0x40213ece: LogStruct::add(char const*) at /home/john/Arduino/scetchbooks/ESPEasy/_P030_BMP280.ino line 390
:  (inlined by) addLog(unsigned char, char const*) at /home/john/Arduino/scetchbooks/ESPEasy/Misc.ino line 1395
0x4023545d: runEach30Seconds() at /home/john/Arduino/scetchbooks/ESPEasy/_P030_BMP280.ino line 390
0x4020c678: timeOutReached(unsigned long) at /home/john/Arduino/scetchbooks/ESPEasy/_P030_BMP280.ino line 390
0x4023eac5: loop at /home/john/Arduino/scetchbooks/ESPEasy/ESPEasy.ino line 436
0x4024bcc8: loop_wrapper at /home/john/ArduinoPortable/arduino-1.8.5_ESPgit/hardware/esp8266com/esp8266/cores/esp8266/core_esp8266_main.cpp line 125
0x40100739: cont_wrapper at /home/john/ArduinoPortable/arduino-1.8.5_ESPgit/hardware/esp8266com/esp8266/cores/esp8266/cont.S line 81

صباح الخير جميعا.
بالنسبة لي ، إعادة الاتصال لا تعمل بعد.

تهيئة: إصدار التمهيد: (ESP82xx Core 2_4_1)
92: تهيئة: التمهيد الدافئ رقم 8
94: خ م: تركيب ...
118: FS: تم التحميل بنجاح ، تم استخدام 76806 بايت من 957314
131: CRC: لم يتم العثور على مجموع اختباري لذاكرة البرنامج. تحقق من إخراج crc2.py
162: اتفاقية حقوق الطفل: إعدادات الأمان اتفاقية حقوق الطفل ... حسنًا
243: تهيئة: ذاكرة وصول : 20968
243: تهيئة: I2C
243: تهيئة: SPI غير ممكّن
1073: معلومات: المكونات الإضافية: 71 [عادي] [اختبار] (ESP82xx Core 2_4_1)
1074: حدث: استيقظ النظام #
1121: WIFI: اضبط WiFi على STA
1153: WIFI: توصيل محاولة SMC # 0
1154: IP: IP ثابت: 192.168.0.201 GW: 192.168.0.3 SN: 255.255.255.0 DNS: 192.168.0.3
1155: WIFI: تختلف حالة محطة SDK عن حالة Arduino. حالة SDK: 1 حالة Arduino: 6
1173: حدث: نظام # التمهيد
1179: ACT: NeoPixelAll ، 0،0،0،0
1190: ACT: انشر ESP-201 / IP، 192.168.0.201
1201: ACT: timerSet، 1،60
1226: WD: وقت التشغيل 0 ConnectFailures 0 FreeMem 20072
1258: DS: درجة الحرارة: 19.75 (28-ff-b8-ea-b4-16-3-ed)
1259: الحدث: DS18b20 # درجة الحرارة = 19.75
4925: WIFI: متصل! AP: SMC (78: 8A: 20: D1: 9B: D9) Ch: 1 المدة: 3770 مللي ثانية
4926: الحدث: WiFi # ChangedAccesspoint
4947: IP: Static IP: 192.168.0.201 GW: 192.168.0.3 SN: 255.255.255.0 DNS: 192.168.0.3
4947: WIFI: تختلف حالة محطة SDK عن حالة Arduino. حالة SDK: 5 حالة Arduino: 3
4953: WIFI: IP ثابت: 192.168.0.201 (ESP-201-1) GW: 192.168.0.3 SN: 255.255.255.0 المدة: 23 مللي ثانية
5066: المنطقة الزمنية الحالية: التوقيت الصيفي البداية: 2018-03-25 02:00:00 الإزاحة: 120 دقيقة بدء وقت STD: 2018-10-28 03:00:00 الإزاحة: 60 دقيقة
5066: الحدث: الوقت # مهيأ
5087: الحدث: WiFi # متصل
5104: خادم الويب: ابدأ
5104: WIFI: تختلف حالة محطة SDK عن حالة Arduino. حالة SDK: 5 حالة Arduino: 3
5186: MQTT: إعادة الاتصال المتعمد
5222: MQTT: متصل بالوسيط بمعرف العميل: ESPClient_5C: CF: 7F: 0B: 68: 52
5225: مشترك في: ESP-201 / #
5226: الحدث: MQTT # متصل
5906: الحدث: الساعة # الوقت = الشمس ، 10:01
31227: WD: Uptime 1 ConnectFailures 0 FreeMem 16336
47905: الحدث: الساعة # الوقت = الشمس ، 10:02
61229: WD: Uptime 1 ConnectFailures 0 FreeMem 16336
61926: DS: درجة الحرارة: 19.75 (28-ff-b8-ea-b4-16-3-ed)
61928: الحدث: DS18b20 # درجة الحرارة = 19.75
61972: الحدث: القواعد # الموقت = 1
61983: ACT: انشر ESP-201 / IP، 192.168.0.201
61999: ACT: انشر ESP-201 / MAC، 5C: CF: 7F: 0B: 68: 52
62015: ACT: انشر ESP-201 / الوقت ، 10:02:14
62030: ACT: انشر ESP-201 / Uptime، 1
62044: ACT: انشر ESP-201 / RSSI، -62
62060: ACT: انشر ESP-201 / SSID، SMC
62076: ACT: نشر ESP-201 / BSSID، 78: 8A: 20: D1: 9B: D9
62091: ACT: انشر ESP-201 / CH، 1
62107: ACT: انشر ESP-201 / SYSHEAP، 13536
62120: ACT: timerSet، 1،60
67292: الحدث: WiFi # غير متصل
67310: WIFI: غير متصل! السبب: "(1) غير محدد" متصل لمدة 1 م 2 ثانية
67310: WIFI: تختلف حالة محطة SDK عن حالة Arduino. حالة SDK: 5 حالة Arduino: 3
67316: MQTT: انقطع الاتصال
67317: الحدث: MQTT # غير متصل
67357: MQTT: فشل الاتصال بالوسيط
67856: MQTT: فشل الاتصال بالوسيط
68606: MQTT: فشل الاتصال بالوسيط
69607: MQTT: فشل الاتصال بالوسيط
70857: MQTT: فشل الاتصال بالوسيط
72357: MQTT: فشل الاتصال بالوسيط
74107: MQTT: فشل الاتصال بالوسيط
76106: MQTT: فشل الاتصال بالوسيط
78107: MQTT: فشل الاتصال بالوسيط
80107: MQTT: فشل الاتصال بالوسيط
82106: MQTT: فشل الاتصال بالوسيط
84106: MQTT: فشل الاتصال بالوسيط
86107: MQTT: فشل الاتصال بالوسيط
88106: MQTT: فشل الاتصال بالوسيط
90107: MQTT: فشل الاتصال بالوسيط
91228: WD: فشل اتصال Uptime 2 30 FreeMem 17368
91250: MQTT: فشل الاتصال بالوسيط
92107: MQTT: فشل الاتصال بالوسيط
94107: MQTT: فشل الاتصال بالوسيط
96106: MQTT: فشل الاتصال بالوسيط
98107: MQTT: فشل الاتصال بالوسيط
100107: MQTT: فشل الاتصال بالوسيط
102107: MQTT: فشل الاتصال بالوسيط
104106: MQTT: فشل الاتصال بالوسيط
106107: MQTT: فشل الاتصال بالوسيط
107905: الحدث: الساعة # الوقت = الشمس ، 10: 03
108107: MQTT: فشل الاتصال بالوسيط
110107: MQTT: فشل الاتصال بالوسيط
112107: MQTT: فشل الاتصال بالوسيط
114107: MQTT: فشل الاتصال بالوسيط
116107: MQTT: فشل الاتصال بالوسيط
118107: MQTT: فشل الاتصال بالوسيط
120107: MQTT: فشل الاتصال بالوسيط
121228: WD: فشل اتصال Uptime 2 62 FreeMem 17368
121249: MQTT: فشل الاتصال بالوسيط
121926: DS: درجة الحرارة: 19.75 (28-ff-b8-ea-b4-16-3-ed)
121927: الحدث: DS18b20 # درجة الحرارة = 19.75
122107: MQTT: فشل الاتصال بالوسيط
122905: الحدث: القواعد # الموقت = 1
122915: ACT: انشر ESP-201 / IP، 0.0.0.0
122927: ACT: انشر ESP-201 / MAC، 5C: CF: 7F: 0B: 68: 52
122939: ACT: انشر ESP-201 / الوقت ، 10:15:15
122950: ACT: انشر ESP-201 / Uptime، 2
122961: ACT: انشر ESP-201 / RSSI، 0
122972: ACT: نشر ESP-201 / SSID ، -
122983: ACT: انشر ESP-201 / BSSID ، 00: 00: 00: 00: 00
122994: ACT: انشر ESP-201 / CH، 0
123005: ACT: انشر ESP-201 / SYSHEAP، 16992
123015: ACT: timerSet، 1،60
124107: MQTT: فشل الاتصال بالوسيط
126106: MQTT: فشل الاتصال بالوسيط
128107: MQTT: فشل الاتصال بالوسيط
130107: MQTT: فشل الاتصال بالوسيط
132107: MQTT: فشل الاتصال بالوسيط
134107: MQTT: فشل الاتصال بالوسيط
136107: MQTT: فشل الاتصال بالوسيط
138107: MQTT: فشل الاتصال بالوسيط
140107: MQTT: فشل الاتصال بالوسيط
142107: MQTT: فشل الاتصال بالوسيط
144107: MQTT: فشل الاتصال بالوسيط
146107: MQTT: فشل الاتصال بالوسيط
148107: MQTT: فشل الاتصال بالوسيط
150107: MQTT: فشل الاتصال بالوسيط
151228: WD: فشل اتصال Uptime 3 94 FreeMem 17368
151249: MQTT: فشل الاتصال بالوسيط
152107: MQTT: فشل الاتصال بالوسيط
154107: MQTT: فشل الاتصال بالوسيط
156107: MQTT: فشل الاتصال بالوسيط
158107: MQTT: فشل الاتصال بالوسيط
160107: MQTT: فشل الاتصال بالوسيط
162107: MQTT: فشل الاتصال بالوسيط
164107: MQTT: فشل الاتصال بالوسيط
166107: MQTT: فشل الاتصال بالوسيط
167905: الحدث: الساعة # الوقت = الشمس ، 10: 04
168107: MQTT: فشل الاتصال بالوسيط
170107: MQTT: فشل الاتصال بالوسيط
172107: MQTT: فشل الاتصال بالوسيط
174106: MQTT: فشل الاتصال بالوسيط
176106: MQTT: فشل الاتصال بالوسيط
178107: MQTT: فشل الاتصال بالوسيط
180107: MQTT: فشل الاتصال بالوسيط
181228: WD: Uptime 3 ConnectFailures 126 FreeMem 17368
181250: MQTT: فشل الاتصال بالوسيط
181926: DS: درجة الحرارة: 19.75 (28-ff-b8-ea-b4-16-3-ed)
181927: الحدث: DS18b20 # درجة الحرارة = 19.75
182107: MQTT: فشل الاتصال بالوسيط
183905: الحدث: القواعد # الموقت = 1
183915: ACT: انشر ESP-201 / IP، 0.0.0.0
183927: ACT: انشر ESP-201 / MAC، 5C: CF: 7F: 0B: 68: 52
183938: ACT: انشر ESP-201 / الوقت ، 10:16:16
183950: ACT: انشر ESP-201 / Uptime، 3
183961: ACT: انشر ESP-201 / RSSI، 0
183972: ACT: نشر ESP-201 / SSID ، -
183983: ACT: انشر ESP-201 / BSSID ، 00: 00: 00: 00: 00: 00
183994: ACT: انشر ESP-201 / CH، 0
184005: ACT: انشر ESP-201 / SYSHEAP، 16992
184015: ACT: timerSet، 1،60
184107: MQTT: فشل الاتصال بالوسيط
186106: MQTT: فشل الاتصال بالوسيط
188107: MQTT: فشل الاتصال بالوسيط
190106: MQTT: فشل الاتصال بالوسيط
192107: MQTT: فشل الاتصال بالوسيط
194106: MQTT: فشل الاتصال بالوسيط
196106: MQTT: فشل الاتصال بالوسيط
198106: MQTT: فشل الاتصال بالوسيط
200106: MQTT: فشل الاتصال بالوسيط
202106: MQTT: فشل الاتصال بالوسيط
204106: MQTT: فشل الاتصال بالوسيط
206106: MQTT: فشل الاتصال بالوسيط
208106: MQTT: فشل الاتصال بالوسيط
210106: MQTT: فشل الاتصال بالوسيط
211228: WD: فشل اتصال Uptime 4 158 FreeMem 17368
211249: MQTT: فشل الاتصال بالوسيط
212106: MQTT: فشل الاتصال بالوسيط
214106: MQTT: فشل الاتصال بالوسيط
216106: MQTT: فشل الاتصال بالوسيط
218106: MQTT: فشل الاتصال بالوسيط
220106: MQTT: فشل الاتصال بالوسيط
222106: MQTT: فشل الاتصال بالوسيط
224106: MQTT: فشل الاتصال بالوسيط
226106: MQTT: فشل الاتصال بالوسيط
227905: الحدث: الساعة # الوقت = الشمس ، 10:05
228107: MQTT: فشل الاتصال بالوسيط
230107: MQTT: فشل الاتصال بالوسيط
232107: MQTT: فشل الاتصال بالوسيط
234107: MQTT: فشل الاتصال بالوسيط
236106: MQTT: فشل الاتصال بالوسيط
238106: MQTT: فشل الاتصال بالوسيط
240106: MQTT: فشل الاتصال بالوسيط
241228: WD: Uptime 4 ConnectFailures 190 FreeMem 17368
241249: MQTT: فشل الاتصال بالوسيط
241925: DS: درجة الحرارة: 19.75 (28-ff-b8-ea-b4-16-3-ed)
241927: الحدث: DS18b20 # درجة الحرارة = 19.75
242107: MQTT: فشل الاتصال بالوسيط
244106: MQTT: فشل الاتصال بالوسيط
244908: الحدث: القواعد # الموقت = 1
244918: ACT: انشر ESP-201 / IP، 0.0.0.0
244930: ACT: انشر ESP-201 / MAC، 5C: CF: 7F: 0B: 68: 52
244942: ACT: انشر ESP-201 / الوقت ، 10:17:17
244953: ACT: انشر ESP-201 / Uptime، 4
244964: ACT: انشر ESP-201 / RSSI، 0
244975: ACT: انشر ESP-201 / SSID ، -
244986: ACT: نشر ESP-201 / BSSID ، 00: 00: 00: 00: 00: 00
244997: ACT: انشر ESP-201 / CH، 0
245008: ACT: انشر ESP-201 / SYSHEAP، 16992
245018: ACT: timerSet، 1،60
246107: MQTT: فشل الاتصال بالوسيط
248106: MQTT: فشل الاتصال بالوسيط
250106: MQTT: فشل الاتصال بالوسيط
252106: MQTT: فشل الاتصال بالوسيط
254106: MQTT: فشل الاتصال بالوسيط
256106: MQTT: فشل الاتصال بالوسيط
258106: MQTT: فشل الاتصال بالوسيط
260106: MQTT: فشل الاتصال بالوسيط
262106: MQTT: فشل الاتصال بالوسيط
264106: MQTT: فشل الاتصال بالوسيط
266107: MQTT: فشل الاتصال بالوسيط

ESP32 - آخر التغييرات (28-04-2018) توقف MQTT عن العمل ، توقف NTP عن العمل
(رقم تعريف حاسوب ثابت)

تضمين التغريدة
لا يفقد MQTT الاتصال كل ثانية إذا لم تقم بالاشتراك وحاولت النشر فقط.

52898 : MQTT : Connection lost
52925 : MQTT : Connected to broker with client ID: ESPClient_2C:3A:E8:06:5E:B2
52926 : Subscribed to: 
53176 : MQTT : Connection lost
53203 : MQTT : Connected to broker with client ID: ESPClient_2C:3A:E8:06:5E:B2
53204 : Subscribed to: 
53498 : MQTT : Connection lost
53527 : MQTT : Connected to broker with client ID: ESPClient_2C:3A:E8:06:5E:B2
53528 : Subscribed to: 
53778 : MQTT : Connection lost
53806 : MQTT : Connected to broker with client ID: ESPClient_2C:3A:E8:06:5E:B2
53807 : Subscribed to: 
54058 : MQTT : Connection lost
54086 : MQTT : Connected to broker with client ID: ESPClient_2C:3A:E8:06:5E:B2
54087 : Subscribed to: 
54337 : MQTT : Connection lost
54363 : MQTT : Connected to broker with client ID: ESPClient_2C:3A:E8:06:5E:B2
54364 : Subscribed to: 
54615 : MQTT : Connection lost
54642 : MQTT : Connected to broker with client ID: ESPClient_2C:3A:E8:06:5E:B2
54643 : Subscribed to: 
54894 : MQTT : Connection lost
54921 : MQTT : Connected to broker with client ID: ESPClient_2C:3A:E8:06:5E:B2
54922 : Subscribed to: 
55172 : MQTT : Connection lost
55199 : MQTT : Connected to broker with client ID: ESPClient_2C:3A:E8:06:5E:B2
55200 : Subscribed to: 
55630 : FILE : Saved config.dat
55692 : FILE : Saved config.dat
55861 : MQTT : Connection lost
55889 : MQTT : Connected to broker with client ID: ESPClient_2C:3A:E8:06:5E:B2

حاول إدخال شيء ما في سطر الاشتراك حتى لو لم تستخدمه. عملت من أجلي.

55630 : FILE : Saved config.dat
55692 : FILE : Saved config.dat
55861 : MQTT : Connection lost
55889 : MQTT : Connected to broker with client ID: ESPClient_2C:3A:E8:06:5E:B2
55890 : Subscribed to: SMA
60404 : WD   : Uptime 1 ConnectFailures 354 FreeMem 19224
90404 : WD   : Uptime 2 ConnectFailures 353 FreeMem 19224
120404 : WD   : Uptime 2 ConnectFailures 352 FreeMem 19224
150404 : WD   : Uptime 3 ConnectFailures 351 FreeMem 19224
180404 : WD   : Uptime 3 ConnectFailures 350 FreeMem 19224
210404 : WD   : Uptime 4 ConnectFailures 349 FreeMem 19224

@ TD- إيه
يتم تحميل هذا الموضوع بشكل زائد قليلاً ويبدو أن هناك العديد من مشكلات wifi / الاستقرار. أقترح نقل جميع المشكلات إلى مشكلة جيثب منفصلة ووضع علامة عليها بكلمة رئيسية ، على سبيل المثال
[WIFICORE] ssdp
[WIFICORE] MQTT subscription needed
[WIFICORE] Unit not found - port setting vanished
[WIFICORE] ticker interval

فقط للإبلاغ ، تمت ترقيته للتو من ميجا 20180428 إلى ميجا 20180429.

في mega-20180428 ، كانت شبكة wifi مستقرة بشكل عام ، لكنها لم تتم إعادة الاتصال بعد انقطاع الاتصال.
في mega-20180429 ، wifi غير مستقر للغاية ولا يمكنني اختبار اتصاله دون الحصول على الكثير من مهلات القراءة.

أنا أستخدم برنامج Sonoff الأساسي ، والإصدارات ذاتية التجميع مع #define PLUGIN_SET_SONOFF_BASIC لجعل الحاوية صغيرة بما يكفي لـ OTA.
لست متأكدًا مما إذا كان ذلك مفيدًا ، والعودة إلى ميجا 20180428 في هذه الأثناء.

@ louis-lau هل يمكنك إعادة الاختبار باستخدام أحدث دمج + التزام قمت به للتو؟

هذا في آخر التزام

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

@ louis-lau a sonoff الأساسية؟
أنا أيضًا أحب 0429 ، 0428 كان فظيعًا
هل يمكنني معرفة المزيد عن إعداداتك "العامة" من فضلك؟
وكمترجمة ذاتيًا ، هل تم تجميعها باستخدام 2.4.1 Core؟
لقد اختبرت للتو 0429 فلاشًا جديدًا على عقدة فارغة ويعمل بشكل مثالي.
كانت محاولتي السابقة مع 0429 تحديثًا لعقدة مجموعة ثابتة تم تكوينها مسبقًا. ممتاز جدا
لوحاتي مؤرخة 5-5-2017

تضمين التغريدة
2.4.2 الأساسية ؟؟؟؟

هذا كل ما حصلت عليه ويبدو أنه مناسب:

04-29-2018  15:43:29    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: EVENT: MQTT#Connected
04-29-2018  15:43:29    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: Subscribed to: /sonoff_lavalamp/#
04-29-2018  15:43:29    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: MQTT : Connected to broker with client ID: ESPClient_5C:CF:7F:71:68:FB
04-29-2018  15:43:29    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: EVENT: Time#Set Processing time:46 milliSeconds
04-29-2018  15:43:29    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: EVENT: Time#Set
04-29-2018  15:43:29    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: NTP  : NTP replied: 20 mSec
04-29-2018  15:43:29    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: NTP  : NTP host time.google.com (216.239.35.8) queried
04-29-2018  15:43:29    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: WIFI  : Arduino wifi status: WL_CONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_SERVICES_INITIALIZED
04-29-2018  15:43:06    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: SW   : GPIO 12 Set to 0
04-29-2018  15:43:06    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: EVENT: MQTT#Connected Processing time:1132 milliSeconds
04-29-2018  15:43:06    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: else = false
04-29-2018  15:43:06    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: SW   : GPIO 13 Set PWM to 1023
04-29-2018  15:43:05    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: [if 0=0]=true
04-29-2018  15:43:05    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: ACT  : timerSet,4,0
04-29-2018  15:43:05    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: ACT  : timerSet,3,0
04-29-2018  15:43:05    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: ACT  : timerSet,2,0
04-29-2018  15:43:05    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: ACT  : timerSet,1,0
04-29-2018  15:43:05    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: EVENT: MQTT#Connected
04-29-2018  15:43:05    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: Subscribed to: /sonoff_lavalamp/#
04-29-2018  15:43:05    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: MQTT : Connected to broker with client ID: ESPClient_5C:CF:7F:71:68:FB
04-29-2018  15:43:05    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: EVENT: Time#Set Processing time:47 milliSeconds
04-29-2018  15:43:05    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: EVENT: Time#Set
04-29-2018  15:43:05    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: NTP  : NTP replied: 20 mSec
04-29-2018  15:43:05    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: NTP  : NTP host time.google.com (216.239.35.8) queried
04-29-2018  15:43:05    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: WIFI  : Arduino wifi status: WL_CONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_SERVICES_INITIALIZED
04-29-2018  15:42:53    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: WD   : Uptime 3 ConnectFailures 2 FreeMem 19456
04-29-2018  15:42:53    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: 2: lowest: 12320  parseTemplate3-> 17112 ruleMatch-> 17088 ruleMatch2-> 17040 parseTemplate-> 17176 parseTemplate3-> 17112 ruleMatch-> 17072 ruleMatch2-> 17008 rulesProcessingFile2-> 17160 sendContentBlocking-> 17184 sendConten
04-29-2018  15:42:47    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: EVENT: MQTT#Connected Processing time:1131 milliSeconds
04-29-2018  15:42:47    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: else = false
04-29-2018  15:42:47    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: SW   : GPIO 13 Set PWM to 1023
04-29-2018  15:42:46    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: [if 0=0]=true
04-29-2018  15:42:46    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: ACT  : timerSet,4,0

Oxyandy سأحاول إعادة ضبط المصنع. لم أقم بإجراء أي تغييرات قبل التجميع ، باستثناء علامة Sonoff الأساسية المكونة الإضافية وإعدادات الشبكة في Custom.h.

أنت على حق ، يعمل بشكل جيد مع إعدادات المصنع 😄.

سأحاول الاستعادة ، ومعرفة ما إذا كان سيتعطل مرة أخرى.

يبدو وكأنه مجرد إعادة تشغيل؟

في سجل الويب ، ستحصل على عدد أكبر قليلاً من الأسطر ، نظرًا لأن ذلك يحتوي على مخزن مؤقت يتكون من 15 سطرًا.
يمكنك أيضًا الحصول على مزيد من المعلومات على صفحة sysinfo.

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

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

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

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

حسنًا ، عندما أوقف خادم mqtt يعمل أيضًا بشكل طبيعي ، فقط عندما يكون الخادم قيد التشغيل ، تنتهي مهلة الاتصال.

هذا كل ما تمكنت من الحصول عليه من السجل:

أي نوع من متحكم MQTT هذا؟ دوموتيكز؟ OpenHAB؟

أم أنك تحاول القيام باستيراد MQTT؟

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

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

باستخدام أحدث إصدار من githib (07bfec42347d13ad49dda907654a36bf747df3bc) ، يتصل Wifi دون مشاكل في جميع العقد الخاصة بي. الآن أيضًا يعيد الاتصال بشكل صحيح بعد إعادة تشغيل AP. باستخدام النواة 2.4.1.

هيه ، بمجرد تحميله بالفعل ، لم يكن لدي سوى القليل من الوقت ، لذلك التقطت لقطة شاشة. أنا أستخدم وحدة تحكم openhab mqtt ، الخادم هو البعوض.

تحرير: لا تستخدم القواعد الآن. فقط للتأكد من أن هذه ليست المشكلة.

كذلك هنا. حاول الاشتراك في أي موضوع. هذا أصلح مشكلتي.

-------- Ursprüngliche Nachricht --------
فون: لويس لوريس [email protected]
Gesendet: 29. أبريل 2018 16:23:54 MESZ
ج: Letscontrolit / ESPEasy [email protected]
CC: s0170071 [email protected] ، أذكر [email protected]
Betreff: Re: [Letscontrolit / ESPEasy] مشكلات Wifi -لا تنتهي القصة أبدًا- هل تعود إلى شبكة wifi غير القائمة على الأحداث؟ (# 1302)

هيه ، بمجرد تحميله بالفعل ، لم يكن لدي سوى القليل من الوقت ، لذلك التقطت لقطة شاشة. أنا أستخدم وحدة تحكم openhab mqtt ، الخادم هو البعوض.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub:
https://github.com/letscontrolit/ESPEasy/issues/1302#issuecomment -385255207

@ s0170071 أين يتم هذا الاشتراك؟
إذا كان هذا في نوع من الإعداد الافتراضي ، فربما يجب أن نضيف ذلك.

هل الوقت بين إعادة توصيل MQTT حوالي 15 - 16 ثانية؟ ثم يمكن أن يكون البعوض يطردك ومن ثم أعرف مكان تصحيح هذا.

في إعدادات تحكم openhab. هناك حقل الاشتراك.

باستخدام أحدث إصدار من githib (07bfec4) ، يعمل MQTT أيضًا دون مشاكل هنا باستخدام وحدة تحكم openhab والاتصال بـ Mosquitto. باستخدام النواة 2.4.1.

@ td-er انظر بعض الوظائف أعلاه.

أنا مشترك بالفعل في / sonoff_lavalamp / # كما ترون في السجلات.

لقد لاحظت عندما اشتركت في # (لذا ، كل الموضوعات). شبكة wifi مستقرة ، لكن هذا يجعل mqtt غير قابل للاستخدام ؛)

لا ينبغي أن يطرد Mosquitto المستخدم ، فالمستخدم الذي أستخدمه لديه أذونات لجميع الموضوعات.

هذا هو سجل البعوض:

1525014154: New client connected from 192.168.2.22 as ESPClient_5C:CF:7F:71:68:FB (c1, k15, u'my_mqtt_username').
1525014168: New connection from 192.168.2.22 on port 1883.
1525014168: Client ESPClient_5C:CF:7F:71:68:FB already connected, closing old connection.
1525014168: Client ESPClient_5C:CF:7F:71:68:FB disconnected.
1525014168: New client connected from 192.168.2.22 as ESPClient_5C:CF:7F:71:68:FB (c1, k15, u'my_mqtt_username').
1525014196: New connection from 192.168.2.22 on port 1883.
1525014196: Client ESPClient_5C:CF:7F:71:68:FB already connected, closing old connection.
1525014196: Client ESPClient_5C:CF:7F:71:68:FB disconnected.
1525014196: New client connected from 192.168.2.22 as ESPClient_5C:CF:7F:71:68:FB (c1, k15, u'my_mqtt_username').
1525014214: New connection from 192.168.2.22 on port 1883.
1525014214: Client ESPClient_5C:CF:7F:71:68:FB already connected, closing old connection.
1525014214: Client ESPClient_5C:CF:7F:71:68:FB disconnected.
1525014214: New client connected from 192.168.2.22 as ESPClient_5C:CF:7F:71:68:FB (c1, k15, u'my_mqtt_username').
1525014226: New connection from 192.168.2.22 on port 1883.
1525014226: Client ESPClient_5C:CF:7F:71:68:FB already connected, closing old connection.
1525014226: Client ESPClient_5C:CF:7F:71:68:FB disconnected.
1525014226: New client connected from 192.168.2.22 as ESPClient_5C:CF:7F:71:68:FB (c1, k15, u'my_mqtt_username').
1525014255: New connection from 192.168.2.22 on port 1883.
1525014255: Client ESPClient_5C:CF:7F:71:68:FB already connected, closing old connection.
1525014255: Client ESPClient_5C:CF:7F:71:68:FB disconnected.
1525014255: New client connected from 192.168.2.22 as ESPClient_5C:CF:7F:71:68:FB (c1, k15, u'my_mqtt_username').
1525014270: New connection from 192.168.2.22 on port 1883.

يبدو أنه يعيد الاتصال ، ويغلق البعوض الاتصال القديم.

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

سأحاول إضافة نوع من ping التلقائي. يوجد بعض بالفعل ، ولكن قد يتم إجراء الفحص قبل عودة اختبار ping.

@ louis-lau هل يمكنك بطريقة ما العثور على إعداد وقت البقاء على قيد الحياة المستخدم في البعوض؟

يبدو أن إعداد مهلة MQTT الذي نستخدمه هو 15 ثانية.
يتم تعريفه على أنه: #define MQTT_KEEPALIVE 15

راجع أيضًا https://github.com/knolleary/pubsubclient/issues/239

واو ، لقد فعلتها @ TD-er !!!!!

467279: الحدث: الساعة # الوقت = الشمس ، 17:24
467588: WD: فشل اتصال Uptime 8 0 FreeMem 16304
481935: MQTT: انقطع الاتصال
481935: الحدث: MQTT # غير متصل
481953: الحدث: WiFi # غير متصل
481969: WIFI: غير متصل! السبب: "(1) غير محدد" متصل لمدة 7 م و 40 ثانية
482278: WIFI: توصيل محاولة SMC رقم 0
482278: IP: Static IP: 192.168.0.201 GW: 192.168.0.3 SN: 255.255.255.0 DNS: 192.168.0.3
483304: الحدث: WiFi # غير متصل
483322: WIFI: غير متصل! السبب: "(202) فشل المصادقة" متصل لمدة 1018 مللي ثانية
484291: WIFI: توصيل محاولة SMC رقم 1
484292: IP: IP ثابت: 192.168.0.201 GW: 192.168.0.3 SN: 255.255.255.0 DNS: 192.168.0.3
488073: WIFI: متصل! AP: SMC (78: 8A: 20: D1: 9B: D9) Ch: 1 المدة: 3780 مللي ثانية
488074: IP: Static IP: 192.168.0.201 GW: 192.168.0.3 SN: 255.255.255.0 DNS: 192.168.0.3
488078: WIFI: IP ثابت: 192.168.0.201 (ESP-201-1) GW: 192.168.0.3 SN: 255.255.255.0 المدة: 6 مللي ثانية
488099: الحدث: WiFi # متصل
488245: MQTT: متصل بالوسيط باستخدام معرف العميل: ESPClient_5C: CF: 7F: 0B: 68: 52
488247: مشترك في: ESP-201 / #
488248: الحدث: MQTT # متصل
489111: الحدث: الوقت # ضبط

@ TD-er هل أنت متأكد من وجود مشكلات لدى pubsubclient؟ لا تتلقى وحدتي أي شيء ، ترسل فقط قيمة تناظرية كل 30 ثانية. لا توجد مشاكل اتصال MQTT. إذا كانت هناك مشكلة في المكتبة ، ألن يكون لدينا الكثير من المستخدمين الذين يشكون؟

ربما تكون حالة سباق ...

يجب على وسيط MQTT اعتبار العميل غير متصل عند 1.5x المهلة.
يقوم Pubsubclient بإرسال اختبار ping عندما مضى أكثر من 15 ثانية على آخر نشاط.
لذلك إذا تم استخدام المهلة الافتراضية لـ Mosquito (10s) ، فإن التوقيت يصبح حرجًا للغاية.

في الإعداد الخاص بي ، أرى الكثير من حركة مرور MQTT لجميع العقد هنا تتحدث على نفس القناة (domoticz).
لذا فإن المهلة ليست مشكلة هنا.
ولكن إذا كانت هناك عقدة واحدة فقط ، فستكون هناك حركة مرور أقل بكثير ومع تعيين مهلة ESPeasy الافتراضية عند 1.5x بالضبط مهلة البعوض الافتراضية ، فقد يكون الأمر حرجًا بعض الشيء.

ثم يمكنه محاولة إرسال قيمة تناظرية وهمية كل 5 ثوانٍ للتحقق مما إذا كانت المشكلة قد اختفت ...

أو استخدم الالتزام الأخير ؛)

كانت عمليات إعادة الاتصال الخاصة بي سريعة جدًا ، كل ثانية أو نحو ذلك

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

التعريف ملفوف بعلامة #ifdef
لذلك هناك خيار لتعريفه في أجزاء أخرى من الكود.

في صفحة github الخاصة بـ PubSubclient ، هناك أيضًا مشكلة تتعلق بجعلها قابلة للتكوين.

تعليق آخر لمؤلفه:
في بروتوكول MQTT ، يحدد العميل قيمة Keepalive المستخدمة في الاتصال. الوسيط ليس له رأي في ذلك.

خيار تكوين Keepalive الوحيد على Mosquitto هو الجسر الذي يحافظ على الحياة - حيث يعمل كعميل متصل بوسيط آخر - https://mosquitto.org/man/mosquitto-conf-5.html

لقد راجعت تكوين البعوض الخاص بي. لا يمكن العثور على أي خيار مهلة للاتصالات

يناقش هذا المستند سلوك المهلة.

والوثيقة تنص على نفس الشيء:

عميل MQTT مسؤول عن تحديد قيمة الاحتفاظ الصحيحة. على سبيل المثال ، يمكنه تكييف الفاصل الزمني لقوة الإشارة الحالية.

إذن من أين تأتي مدة الـ 10 ثوانٍ من وقت البعوض؟ هل هو صلب؟

https://mosquitto.org/man/mosquitto-conf-5.html

keepalive_interval ثواني
قم بتعيين عدد الثواني التي يجب على الجسر بعدها إرسال أمر ping إذا لم تحدث حركة مرور أخرى. الإعداد الافتراضي هو 60. يُسمح بحد أدنى 5 ثوانٍ.

هذا الإعداد هو فقط من أجل الجسور

ضع في اعتبارك أن هذه لم تكن مشكلة في 20180428 :)

تحرير: سأحاول الالتزام الأخير الخاص بك عندما أصل إلى المنزل.

يمكنك محاولة تعطيل connectionCheckHandler .

لمعرفة ما تغير في اليوم الأخير: https://github.com/letscontrolit/ESPEasy/compare/mega@٪7B1day٪7D...mega

تم التحديث للتو إلى https://github.com/letscontrolit/ESPEasy/commit/4e6e31fdae11476a2f3dfce00e01ed77d1858c00 وأصبح wifi الآن مستقرًا. كما أنه يعيد الاتصال الآن عند إعادة تشغيل نقطة الوصول الخاصة بي! شكرا 😄

(راجع للشغل ، هل هناك أي طريقة لتبديل إعداد Wifi Status LED باستخدام القواعد؟ على سبيل المثال ، أود فقط تمكينه إذا تم فصل mqtt ، واستخدامه في حالة الترحيل عند الاتصال.)

لست متأكدًا من حالة LED. يتم استدعاؤه من وظيفة MQTTconnect ومن عدة أماكن أخرى.
ولكن ربما يمكنك إضافة مشكلة لجعلها قابلة للتحديد ، ما الذي يتم عرضه عبر مؤشر LED هذا؟

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

هل يمكنك جعل نافذة LOG أطول قليلاً؟
يعني زيادة عدد الخطوط.

وإلا فإن الأمور تسير على ما يرام الآن.

أنا فقط خفضتهم.
كانت عبارة عن 20 سطرًا ، ولكن مع 2.4.0 كان يجب أن يكون هناك ذاكرة مجانية أكثر قليلاً ، لذلك قمت بتقليلها إلى 10 سطور للتطوير / الاختبار و 15 للعادي.

سأبحث في استهلاك الذاكرة هذا الأسبوع

حسنا أذهب إلى النوم.
شكرا جزيلا لعملكم الشاق !!

حول تلك النافذة. كما أراه هناك ثلاثة خيارات.

1. استخدم أكبر قدر ممكن من ذاكرة الوصول العشوائي المتاحة للاحتفاظ بالمعلومات حتى يتم طلبها. يمكن أن تكون ديناميكية ، بناءً على عدد المكونات الإضافية النشطة.
2. دفقه إلى Webbrowser.
3. قم بضغطه مؤقتًا واستعادته عند الطلب. على سبيل المثال ، استخدم المزيد من الرموز الرقمية. إنه أقل قابلية للقراءة بالطبع.

أنا أحب 2. يعطي عرض ويب سلسًا أيضًا. لكن الأمر ليس بهذه البساطة.

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

كائن ذاكرة التخزين المؤقت للسجل غير فعال مع الذاكرة في الوقت الحالي. مجال كبير للتحسين.

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

فقط من أجل الفهم ...
لماذا أصبح مباشرًا بعد تشغيل المرساب الكهروستاتيكي الخاص بي:

Last Disconnect Reason str |  (1) Unspecified
Number reconnects | 1

في سجل النظام ، أرى رسالتين IP ثابتتين ووقت التشغيل 0 ConnectFailures 0:

INIT : Booting version: mega-20180430 (ESP82xx Core 2_4_1)
104 : INIT : Warm boot #1
105 : FS   : Mounting...
130 : FS   : Mount successful, used 75802 bytes of 957314
419 : CRC  : program checksum       ...OK
426 : CRC  : SecuritySettings CRC   ...OK 
532 : INIT : Free RAM:23528
532 : INIT : I2C
532 : INIT : SPI not enabled
546 : INFO : Plugins: 47 [Normal] (ESP82xx Core 2_4_1)
546 : WIFI : Set WiFi to STA
578 : WIFI : Connecting im6shop attempt #0
579 : IP   : Static IP : 192.168.1.17 GW: 0.0.0.0 SN: 0.0.0.0 DNS: 0.0.0.0
585 : WD   : Uptime 0 ConnectFailures 0 FreeMem 22688
4342 : WIFI : Connected! AP: im6shop (30:B5:C2:EB:DB:7D) Ch: 9 Duration: 3763 ms
4343 : IP   : Static IP : 192.168.1.17 GW: 0.0.0.0 SN: 0.0.0.0 DNS: 0.0.0.0
4346 : WIFI : Static IP: 0.0.0.0 (ESP-Easy-7) GW: 0.0.0.0 SN: 0.0.0.0   duration: 3 ms
4356 : Webserver: start
4710 : WIFI : Static IP: 192.168.1.32 (ESP-Easy-7) GW: 192.168.1.1 SN: 255.255.255.0   duration: 356 ms

ربما لم يتم اختيار مصطلح "إعادة الاتصال" بشكل جيد.
إنه أشبه بـ "(إعادة) الاتصال" أو "محاولات الاتصال"
يبدأ العداد من 0 وفي كل محاولة اتصال يكون عدادًا ++.

لقد غيرت العداد بتهيئته إلى "-1". لذا فإن محاولة الاتصال الأولى ستحدده على 0 ، وبالتالي فإن التسمية "إعادة توصيل الرقم" أصبحت منطقية مرة أخرى :)
لم أستطع التفكير في اسم أفضل ، لذلك قمت بتغيير القيمة المبلغ عنها ؛)

لا تزال التسمية الصحيحة هي أصعب جزء في البرمجة.

يبدو جيدا !

محاولة الاتصال x

لسوء الحظ ، لا يعمل الإصدار الأخير 20180503 (4096 dev) بالنسبة لي - لا يتم فتح شبكة ESP ، وبدلاً من ذلك يتوقف عن الاستجابة في وحدة التحكم التسلسلية (بعد محاولة الويب المفتوحة). إعادة تعيين الإعدادات إلى الإعدادات الافتراضية وتعيين WifiSSID فقط والمفتاح من خلال وحدة التحكم التسلسلية. يعمل PING ، بدون إعادة تشغيل ، ولا توجد رسالة خطأ.

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

نعم ، لقد حاولت إعادة التشغيل البارد في الأوقات الصعبة ، ولا تزال كما هي. تم الاختبار مع MSIE و Firefox على Win7. سأختبر الجهاز في موقع آخر بعد دقيقتين (جهاز كمبيوتر / نظام تشغيل مختلف ، نقطة وصول مختلفة).
مباشرة بعد الفلاش أعيد تشغيله وشنق.

لقد جربته الآن بالإصدار العادي. من جانبي ، لا توجد مشاكل. لا توجد قوة على إعادة التعيين ضرورية.

من الغريب في مكان آخر أن يعمل ويب ESP الخاص بالجهاز نفسه (Win10 + Firefox / MS Edge ، نقطة وصول مختلفة) لكن وحدة التحكم التسلسلية تبدو "للقراءة فقط" ...: - /
تحديث - جرب تطبيقًا طرفيًا آخر - نفس وحدة التحكم التسلسلية للقراءة فقط. ثم قم بتشغيل المعجون (وهو تطبيقي الافتراضي) مرة أخرى وشاهد إعادة تشغيل الجهاز بمجرد توصيل المعجون بمنفذ COM المناسب. الآن تقبل وحدة التحكم التسلسلية الأوامر ويعمل الويب أيضًا ... لا أفهم أي شيء ...

ربما حاول المسح الكامل للفلاش والبرنامج مرة أخرى؟
يبدو أن هناك علاقة باتصال wifi وما إذا كان المنفذ التسلسلي قيد القراءة. لقد رأيت شخصًا يذكر ذلك في موضوع. لست متأكدًا مما إذا كان ذلك يتعلق بمشكلة PlatformIO أو على LWIP.
لقد كنت أقرأ كثيرًا مؤخرًا ؛)

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

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

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

Oxyandy سأقوم الآن بدفع تغيير PlatformIO.ini لاستخدام LWIP2_LOW_MEMORY.
هل يمكنك اختبار هذا من فضلك؟
وأيضًا السؤال عما إذا كنت تستخدم المهمة / الجهاز 12؟
لقد اختبرته للتو على العقدة الخاصة بي وفصلته على الفور تقريبًا + رفض الاتصال بالإنترنت مرة أخرى.
كان ذلك مع LWIP1.4

وأيضًا السؤال عما إذا كنت تستخدم المهمة / الجهاز 12؟

في الاختبارات ، ليس فقط الأول ، مفتاح واحد
نعم ، هناك 15 ملفًا تم تغييره في GitHub Desktop يتم سحبها الآن

جيد مترجم ، خادم ويب رائع ، باستخدام LWIP2_LOW_MEMORY ، اختبار F5 ، رائع ..
لا توجد علامة على LmacRxBlk: 1 في السجلات
لقد مسحت جميع الإعدادات على Node ، لكنني سأعيد ضبطها وأواصل العملية ، وأبلغ عن أي شذوذ ..
واي فاي متصل على الفور انطلق أولاً ..

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

أنا أستخدم حاليًا الفرع الضخم مع esp core من GIT و lwIP2 ذي النطاق الترددي العالي الذي يعمل بشكل جيد ، إلا بعد مرور بعض الوقت ، لا تستطيع بعض الوحدات قراءة قيم المستشعرات بعد الآن ، وبالتالي لن ترسلها إلى وحدة التحكم. تعمل الوحدة نفسها بالإضافة إلى واجهة الويب بسلاسة على الرغم من ...

لقد جربنا النطاق الترددي العالي LwIP2 ورسائل POST الفاسدة.
على سبيل المثال ، تم قطع قواعد الحفظ> 1520 بايت.

ESP_Easy_mega-20180504_normal_ESP8266_1024.bin
يقصد بهجوم DoS على خوادم الوقت؟
بعد أن تومض ، تم الاتصال بعيدًا ، لدي صفحات وصفحات من هذه الحلقة

INIT : Booting version: mega-20180504 (ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3)
105 : INIT : Cold Boot
106 : FS   : Mounting...
113 : FS   : Mount successful, used 76053 bytes of 113201
15:40:37: 410 : CRC  : program checksum       ...OK
417 : CRC  : SecuritySettings CRC   ...OK 
418 : CRC  : binary has changed since last save of Settings
433 : INIT : Free RAM:23448
434 : INIT : I2C
434 : INIT : SPI not enabled
449 : INFO : Plugins: 47 [Normal] (ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3)
449 : EVENT: System#Wake
458 : WIFI : Set WiFi to STA
mode : sta(5c:cf:7f:72:96:ec)
add if0
491 : WIFI : Connecting MAD_IOT attempt #0
492 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
STUB: dhcp_stop
505 : EVENT: System#Boot
514 : SW   : Switch state 1 Output value 1
517 : EVENT: Float_SW#Switch=1.00
530 : ACT  : Publish domoticz/in,{"idx":66,"nvalue":0,"svalue":"FLOAT_SWITCH_1_00:00:00"}
541 : Command: publish
1004 : WD   : Uptime 0 ConnectFailures 0 FreeMem 22736
15:40:39: scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt 
15:40:41: 
connected with MAD_IOT, channel 13
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
4480 : WIFI : Connected! AP: MAD_IOT (F4:F2:6D:25:84:C6) Ch: 13 Duration: 3986 ms
4485 : EVENT: WiFi#ChangedAccesspoint
4497 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
4499 : WIFI : Static IP: 192.168.0.225 (ESP-Easy-0) GW: 192.168.0.254 SN: 255.255.255.0   duration: 19 ms
4517 : EVENT: WiFi#Connected
4525 : Webserver: start
4526 : WIFI  : Arduino wifi status: WL_CONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_SERVICES_INITIALIZED
5015 : NTP  : NTP host au.pool.ntp.org (129.250.35.250) queried
5066 : NTP  : NTP replied: 50 mSec
5068 : Current Time Zone:  DST time start: 2018-10-07 01:00:00 offset: 660 minSTD time start: 2018-04-01 01:00:00 offset: 600 min
5071 : EVENT: Time#Initialized
5082 : EVENT: Time#Initialized Processing time:11 milliSeconds
5083 : EVENT: Clock#Time=Fri,15:40
5089 : EVENT: Clock#Time=Fri,15:40 Processing time:6 milliSeconds
5091 : MQTT : Intentional reconnect
5091 : LoadFromFile: config.dat index: 28672 datasize: 336
5221 : MQTT : Connected to broker with client ID: ESPClient_5C:CF:7F:72:96:EC
5222 : Subscribed to: domoticz/out
5224 : EVENT: MQTT#Connected
5234 : EVENT: MQTT#Connected Processing time:9 milliSeconds
15:40:43: ping 1, timeout 0, total payload 32 bytes, 1365 ms
15:40:48: bcn_timout,ap_probe_send_start
15:40:50: ap_probe_send over, rest wifi status to disassoc
state: 5 -> 0 (1)
rm 0
13912 : EVENT: WiFi#Disconnected
13919 : WIFI : Disconnected! Reason: '(200) Beacon timeout' Connected for 9432 ms
13930 : MQTT : Connection lost
13931 : EVENT: MQTT#Disconnected
14514 : WIFI : Connecting MAD_IOT attempt #0
14515 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
15:40:51: scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt 
15:40:52: 
connected with MAD_IOT, channel 13
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
16258 : WIFI : Connected! AP: MAD_IOT (F4:F2:6D:25:84:C6) Ch: 13 Duration: 1738 ms
16260 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
16269 : WIFI : Static IP: 192.168.0.225 (ESP-Easy-0) GW: 192.168.0.254 SN: 255.255.255.0   duration: 11 ms
16288 : EVENT: WiFi#Connected
16295 : WIFI  : Arduino wifi status: WL_CONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_SERVICES_INITIALIZED
16389 : LoadFromFile: config.dat index: 28672 datasize: 336
16425 : MQTT : Connected to broker with client ID: ESPClient_5C:CF:7F:72:96:EC
16426 : Subscribed to: domoticz/out
16427 : EVENT: MQTT#Connected
16434 : EVENT: MQTT#Connected Processing time:6 milliSeconds
16557 : NTP  : NTP host au.pool.ntp.org (129.250.35.250) queried
16599 : NTP  : NTP replied: 40 mSec
16600 : EVENT: Time#Set
16606 : EVENT: Time#Set Processing time:5 milliSeconds
15:40:54: ping 1, timeout 0, total payload 32 bytes, 1022 ms
15:40:59: bcn_timout,ap_probe_send_start
15:41:01: ap_probe_send over, rest wifi status to disassoc
state: 5 -> 0 (1)
rm 0
25176 : EVENT: WiFi#Disconnected
25183 : WIFI : Disconnected! Reason: '(200) Beacon timeout' Connected for 8919 ms
25194 : MQTT : Connection lost
25195 : EVENT: MQTT#Disconnected
25514 : WIFI : Connecting MAD_IOT attempt #0
25515 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt 
15:41:02: 
connected with MAD_IOT, channel 13
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
26186 : WIFI : Connected! AP: MAD_IOT (F4:F2:6D:25:84:C6) Ch: 13 Duration: 666 ms
26189 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
26197 : WIFI : Static IP: 192.168.0.225 (ESP-Easy-0) GW: 192.168.0.254 SN: 255.255.255.0   duration: 11 ms
26217 : EVENT: WiFi#Connected
26224 : WIFI  : Arduino wifi status: WL_CONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_SERVICES_INITIALIZED
26318 : LoadFromFile: config.dat index: 28672 datasize: 336
26344 : MQTT : Connected to broker with client ID: ESPClient_5C:CF:7F:72:96:EC
26345 : Subscribed to: domoticz/out
26346 : EVENT: MQTT#Connected
26353 : EVENT: MQTT#Connected Processing time:7 milliSeconds
15:41:04: ping 1, timeout 1, total payload 0 bytes, 1022 ms
27623 : NTP  : NTP host au.pool.ntp.org (129.250.35.250) queried
27664 : NTP  : NTP replied: 41 mSec
27665 : EVENT: Time#Set
27671 : EVENT: Time#Set Processing time:6 milliSeconds
27672 : EVENT: Clock#Time=Fri,15:41
27677 : EVENT: Clock#Time=Fri,15:41 Processing time:5 milliSeconds
ping 1, timeout 0, total payload 32 bytes, 1024 ms
15:41:07: 31004 : WD   : Uptime 1 ConnectFailures 4 FreeMem 19304
15:41:10: bcn_timout,ap_probe_send_start
15:41:12: pm open,type:2 0
ap_probe_send over, rest wifi status to disassoc
state: 5 -> 0 (1)
rm 0
pm close 7
36143 : MQTT : Connection lost
36144 : EVENT: MQTT#Disconnected
36151 : EVENT: WiFi#Disconnected
36156 : WIFI : Disconnected! Reason: '(200) Beacon timeout' Connected for 9948 ms
36514 : WIFI : Connecting MAD_IOT attempt #0
36515 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt 
15:41:13: 
connected with MAD_IOT, channel 13
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
37145 : WIFI : Connected! AP: MAD_IOT (F4:F2:6D:25:84:C6) Ch: 13 Duration: 625 ms
37147 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
37155 : WIFI : Static IP: 192.168.0.225 (ESP-Easy-0) GW: 192.168.0.254 SN: 255.255.255.0   duration: 10 ms
37176 : EVENT: WiFi#Connected
37182 : WIFI  : Arduino wifi status: WL_CONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_SERVICES_INITIALIZED
37276 : LoadFromFile: config.dat index: 28672 datasize: 336
37296 : MQTT : Connected to broker with client ID: ESPClient_5C:CF:7F:72:96:EC
37297 : Subscribed to: domoticz/out
37298 : EVENT: MQTT#Connected
37306 : EVENT: MQTT#Connected Processing time:8 milliSeconds
37551 : NTP  : NTP host au.pool.ntp.org (129.250.35.250) queried
37592 : NTP  : NTP replied: 41 mSec
37593 : EVENT: Time#Set
37599 : EVENT: Time#Set Processing time:6 milliSeconds
15:41:15: ping 1, timeout 0, total payload 32 bytes, 1046 ms
15:41:20: bcn_timout,ap_probe_send_start
15:41:22: ap_probe_send over, rest wifi status to disassoc
state: 5 -> 0 (1)
rm 0
46076 : MQTT : Connection lost
46076 : EVENT: MQTT#Disconnected
46083 : EVENT: WiFi#Disconnected
46089 : WIFI : Disconnected! Reason: '(200) Beacon timeout' Connected for 8921 ms
46514 : WIFI : Connecting MAD_IOT attempt #0
46515 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt 

مع النواة الحالية (Master ، ESP82xx Core 41a64707 ، NONOS SDK 2.2.1 (cfd48f3)) لم تعد مشاكل MTU تظهر.
تشغيل 10 ESPs (Sonoff ، NodeMcu ، W1pro) منذ الأول من مايو بدون أي مشاكل.

لمعلوماتك ... قم ببدء تشغيل أحدث إصدار رسمي ، وإعادة تعيين الإعدادات من خلال التسلسل إلى الإعدادات الافتراضية ، وإدخال WiFiSSID والمفاتيح. تعذر الاتصال بـ AP الأساسي على الرغم من أنه كان مرئيًا (لكن إشارة ضعيفة حوالي -82). ثم تحطمت كما ترى أدناه.
في جهاز موقع آخر متصل بنقطة وصول ثانوية بسرعة دون أي مشكلة وهو يعمل حتى الآن (ولكن لم يتم تكوين مكونات إضافية ، ولا توجد قواعد نشطة).
....
....
458745: WIFI: توصيل محاولة IOTAP1 رقم 57
458749: وضع AP: العميل غير متصل: xx: xx: xx: xx: xx: xx الأجهزة المتصلة: 0
458810: WIFI: غير متصل! السبب: '(201) لم يتم العثور على AP' متصل لمدة 64 مللي ثانية
459360: وضع AP: العميل متصل: xx: xx: xx: xx: xx: xx الأجهزة المتصلة: 1
471739: WIFI: AP Mode ssid سيكون ESP_Easy_0 بالعنوان 192.168.4.1
471739: WIFI: توصيل محاولة IOTAP2 رقم 58

استثناء (29):
epc1 = 0x4000e1c3 epc2 = 0x00000000 epc3 = 0x40000f68 excvaddr = 0x00000018 depc = 0x00000000

ctx: sys
sp: 3ffffc50 النهاية: 3fffffb0 الإزاحة: 01a0

كومة >>>
3ffffdf0: 3fff5108 1f385062 401021e6 3fffa2b0
3ffffe00: 402706a6 402705c4 3fff9454 40100eb6
3ffffe10: 3ffeb6d5 401042bb 3ffef160 4026a718
3ffffe20: 00000018 3ffefb30 3ffefaac 00000000
3ffffe30: 40270767 3ff20a00 3fff9454 3ffedf1a
3ffffe40: 3ffedf00 00000000 00000000 00000006
3ffffe50: 00000021 1f4328f4 401021e6 3ffedf00
3ffffe60: 3ffedf1a 0000002c 00000008 401004f4
3ffffe70: 3ffedf0a 3fff6454 4026d324 3ff20a00
3ffffe80: 3fff9454 3fff55c4 00000015 4026d1f7
3ffffe90: 3fffc278 40101f80 3fffc200 00000022
3ffffea0: 3ffebf74 00000000 00000000 3fff4fe4
3ffffeb0: 40000f68 00000030 00000010 ffffffff
3ffffec0: 40000f58 00000000 00000020 00000000
3ffffed0: 3ffef7d4 7fffffff 00000000 3ffeed30
3ffee0: 3ffef138 00000006 00000000 3fffdab0
3ffffef0: 00000000 3fffdcc0 00000040 00000030
3fffff00: 40274fd1 ffffffe0 00000000 00000000
3fffff10: 4026ca2f 3ffedf00 3ffef160 3fff9454
3fffff20: 00000000 3ffedf0a 3ffedf20 4026a4d1
3fffff30: 4027fac5 00000001 00000000 3ffedf0a
3fffff40: 4027ec78 00000092 3ffedef4 3fff6454
3fffff50: 3ffedef4 00000000 00000040 4027e5a2
3fffff60: 3ffef160 3ffedef4 3fffdcc0 3ffeb710
3fffff70: 3ffedf10 3fff752c 00000040 3ffeb710
3fffff80: 00000040 3ffef160 00000002 00000000
3fffff90: 4027de7f 3fffdab0 00000000 40283f5f
3fffffa0: 3ffeb710 40000f49 3fffdab0 40000f49
<<

8 كانون الثاني (يناير) 2013 ، السبب الأول

تحميل 0x4010f000 ، لين 1384 ، غرفة 16
الذيل 8
chksum 0x2d
كسوم 0x2d
v614f7c32
~ لد
-U88:

تهيئة: إصدار التمهيد: mega-20180504 (ESP82xx Core 2_4_1 ، NONOS SDK 2.2.1 (cfd48f3) ، LWIP: 2.0.3)
89: تهيئة: التمهيد الدافئ # 6
90: خ م: تركيب ...
116: FS: تم التحميل بنجاح ، تم استخدام 75802 بايت من 957314
436: اتفاقية حقوق الطفل: المجموع الاختباري للبرنامج ... حسنًا
442: اتفاقية حقوق الطفل: إعدادات الأمان اتفاقية حقوق الطفل ... حسنًا
548: تهيئة: ذاكرة RAM مجانية
549: تهيئة: I2C
549: تهيئة: SPI غير ممكّن
565: INFO: المكونات الإضافية: 72 [عادي] [اختبار] [تطوير] (ESP82xx Core 2_4_1 ، NONOS SDK 2.2.1 (cfd48f3) ، LWIP: 2.0.3)
566: WIFI: اضبط WiFi على STA
599: WIFI: توصيل محاولة IOTAP1 # 0
607: WD: وقت التشغيل 0 ConnectFailures 0 FreeMem 20616
3461: WIFI: غير متصل! السبب: '(201) لم يتم العثور على AP' متصل لمدة 2861 مللي ثانية
3604: WIFI: توصيل محاولة IOTAP1 رقم 1
6466: WIFI: غير متصل! السبب: '(201) لم يتم العثور على AP' متصل لمدة 2862 مللي ثانية
6604: WIFI: توصيل محاولة IOTAP2 رقم 2
9467: WIFI: غير متصل! السبب: '(201) لم يتم العثور على AP' متصل لمدة 2862 مللي ثانية
9604: WIFI: توصيل محاولة IOTAP2 رقم 3
12467: WIFI: غير متصل! السبب: '(201) لم يتم العثور على AP' متصل لمدة 2862 مللي ثانية
12604: WIFI: توصيل محاولة IOTAP1 رقم 4
15466: WIFI: غير متصل! السبب: '(201) لم يتم العثور على AP' متصل لمدة 2862 مللي ثانية
15604: WIFI: توصيل محاولة IOTAP1 رقم 5
18466: WIFI: غير متصل! السبب: '(201) لم يتم العثور على AP' متصل لمدة 2862 مللي ثانية
18604: WIFI: اضبط WiFi على AP + STA
19524: WIFI: AP Mode ssid سيكون ESP_Easy_0 بالعنوان 192.168.4.1
19524: WIFI: توصيل محاولة IOTAP2 رقم 6
22388: WIFI: غير متصل! السبب: '(201) لم يتم العثور على AP' متصل لمدة 2863 مللي ثانية
22603: WIFI: AP Mode ssid سيكون ESP_Easy_0 بالعنوان 192.168.4.1
22603: WIFI: توصيل محاولة IOTAP2 رقم 7
25463: WIFI: غير متصل! السبب: '(201) لم يتم العثور على AP' متصل لمدة 2860 مللي ثانية
25602: WIFI: AP Mode ssid سيكون ESP_Easy_0 بالعنوان 192.168.4.1
25603: WIFI: توصيل محاولة IOTAP1 رقم 8
28464: WIFI: غير متصل! السبب: '(201) لم يتم العثور على AP' متصل لمدة 2860 مللي ثانية
28602: WIFI: AP Mode ssid سيكون ESP_Easy_0 بالعنوان 192.168.4.1
28603: WIFI: توصيل محاولة IOTAP1 رقم 9
30606: WD: فشل الاتصال 1 في وقت التشغيل 0 FreeMem 18176
...
...

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

يجب إجراء تحديثات Oxyandy NTP بعد ساعة فقط ، أو عندما لا يتم تعيينها.

susisstrolch هل يمكنك اختبار كتابة ملف قواعد يحتوي على> 1800 بايت؟
كان إصدار النطاق الترددي العالي LWIP2 يفسد طلبات HTTP POST عندما تتجاوز حجم MTU واحد.

مرحبا جيجس ،
ESP_Easy_mega-20180504_normal_ESP8266_1024.bin
إذا رأيت السجل ، فهو نمط ، يتصل دائمًا ، يتصل MQTT ، ويحدث الوقت

bcn_timout,ap_probe_send_start
ap_probe_send over, rest wifi status to disassoc
state: 5 -> 0 (1)
rm 0
pm close 7
2515788 : EVENT: WiFi#DisconnectedDisconnected! Reason: '(200) Beacon timeout' Connected for 8919 ms

كل 10 إلى 12 ثانية ، مع تكرار مثل هذا لساعات ، عفوًا

حجم قاعدة جهاز pondctrl الخاص بي: الحجم الحالي: 1859 حرفًا (بحد أقصى 2048 حرفًا)
MTU: 534 (ذاكرة منخفضة lwip 2.x)
لا توجد مشاكل - تم تغييره عدة مرات هذا الأسبوع.

نحن نستخدم حاليًا LwIP 2.x ذاكرة منخفضة ، لأن إصدار النطاق الترددي العالي كان يسبب هذه المشكلات.
Oxyandy سأبحث في الكود فيما يتعلق بتحديث الوقت وبالطبع حلقة إعادة الاتصال.
أصبح هذا الموضوع أكثر فأكثر عن الموضوع :(

لا أفهم ذلك ، لقد جمعت المشروب المنزلي (هذا الصباح) بناءً على طلبك بشكل رائع ..
ثم عندما كان الإصدار الرسمي متاحًا اعتقدت أنه من الأفضل استخدام ذلك ، صدمت بالفرق ..
الآن فيما يتعلق بردك الأخير .. تحديث الوقت جيد ..
الإصدار الرسمي من اليوم يتصل بشبكة wifi ، ولا توجد مشكلة ، ويربط MQTT ، ويحصل على الوقت ، ثم ينقطع الاتصال بـ "(200) Beacon timeout" ثم يتكرر كل 11 ثانية
الاتصال - wifi ، MQTT ، الوقت ، قطع الاتصال ، كرر
لذلك لا تنظر إلى "تحديث الوقت" ، إذا ظل متصلاً ، فسيكون ذلك جيدًا ...

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

من المحتمل أن يكون في أعلام المترجم أو الرابط. يمكن أن يكون التحسين عقبة.
يحتوي Arduino IDE على ملف التكوين هذا (platform.txt)

# ESP8266 platform
# ------------------------------

# For more info:
# https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5---3rd-party-Hardware-specification

name=ESP8266 Modules
version=2.5.0-dev

runtime.tools.xtensa-lx106-elf-gcc.path={runtime.platform.path}/tools/xtensa-lx106-elf
runtime.tools.esptool.path={runtime.platform.path}/tools/esptool

compiler.warning_flags=-w
compiler.warning_flags.none=-w
compiler.warning_flags.default=
compiler.warning_flags.more=-Wall
compiler.warning_flags.all=-Wall -Wextra

build.lwip_lib=-llwip_gcc
build.lwip_include=lwip/include
build.lwip_flags=-DLWIP_OPEN_SRC

build.vtable_flags=-DVTABLES_IN_FLASH

build.float=-u _printf_float -u _scanf_float
build.led=

compiler.path={runtime.tools.xtensa-lx106-elf-gcc.path}/bin/
compiler.sdk.path={runtime.platform.path}/tools/sdk
compiler.libc.path={runtime.platform.path}/tools/sdk/libc/xtensa-lx106-elf
compiler.cpreprocessor.flags=-D__ets__ -DICACHE_FLASH -U__STRICT_ANSI__ "-I{compiler.sdk.path}/include" "-I{compiler.sdk.path}/{build.lwip_include}" "-I{compiler.libc.path}/include" "-I{build.path}/core"

compiler.c.cmd=xtensa-lx106-elf-gcc
compiler.c.flags=-c {compiler.warning_flags} -Os -g -Wpointer-arith -Wno-implicit-function-declaration -Wl,-EL -fno-inline-functions -nostdlib -mlongcalls -mtext-section-literals -falign-functions=4 -MMD -std=gnu99 -ffunction-sections -fdata-sections

compiler.S.cmd=xtensa-lx106-elf-gcc
compiler.S.flags=-c -g -x assembler-with-cpp -MMD -mlongcalls

compiler.c.elf.flags=-g {compiler.warning_flags} -Os -nostdlib -Wl,--no-check-sections -u app_entry {build.float} -Wl,-static "-L{compiler.sdk.path}/lib" "-L{compiler.sdk.path}/ld" "-L{compiler.libc.path}/lib" "-T{build.flash_ld}" -Wl,--gc-sections -Wl,-wrap,system_restart_local -Wl,-wrap,spi_flash_read

compiler.c.elf.cmd=xtensa-lx106-elf-gcc
compiler.c.elf.libs=-lhal -lphy -lpp -lnet80211 {build.lwip_lib} -lwpa -lcrypto -lmain -lwps -laxtls -lespnow -lsmartconfig -lairkiss -lwpa2 -lstdc++ -lm -lc -lgcc

compiler.cpp.cmd=xtensa-lx106-elf-g++
compiler.cpp.flags=-c {compiler.warning_flags} -Os -g -mlongcalls -mtext-section-literals -fno-exceptions -fno-rtti -falign-functions=4 -std=c++11 -MMD -ffunction-sections -fdata-sections

compiler.as.cmd=xtensa-lx106-elf-as

compiler.ar.cmd=xtensa-lx106-elf-ar
compiler.ar.flags=cru

compiler.elf2hex.cmd=esptool
compiler.elf2hex.flags=

compiler.size.cmd=xtensa-lx106-elf-size

compiler.esptool.cmd=esptool
compiler.esptool.cmd.windows=esptool.exe

# This can be overriden in boards.txt
build.extra_flags=-DESP8266

# These can be overridden in platform.local.txt
compiler.c.extra_flags=
compiler.c.elf.extra_flags=
compiler.S.extra_flags=
compiler.cpp.extra_flags=
compiler.ar.extra_flags=
compiler.objcopy.eep.extra_flags=
compiler.elf2hex.extra_flags=

## generate file with git version number
## needs bash, git, and echo
recipe.hooks.core.prebuild.1.pattern=bash -c "mkdir -p {build.path}/core && echo \#define ARDUINO_ESP8266_GIT_VER 0x`git --git-dir {runtime.platform.path}/.git rev-parse --short=8 HEAD 2>/dev/null || echo ffffffff` >{build.path}/core/core_version.h"
recipe.hooks.core.prebuild.2.pattern=bash -c "mkdir -p {build.path}/core && echo \#define ARDUINO_ESP8266_GIT_DESC `cd {runtime.platform.path}; git describe --tags 2>/dev/null || echo unix-{version}` >>{build.path}/core/core_version.h"
## windows-compatible version without git
recipe.hooks.core.prebuild.1.pattern.windows=cmd.exe /c mkdir {build.path}\core & (echo #define ARDUINO_ESP8266_GIT_VER 0x00000000 & echo #define ARDUINO_ESP8266_GIT_DESC win-{version} ) > {build.path}\core\core_version.h
recipe.hooks.core.prebuild.2.pattern.windows=

## Build the app.ld linker file
recipe.hooks.linking.prelink.1.pattern="{compiler.path}{compiler.c.cmd}" -CC -E -P {build.vtable_flags} "{runtime.platform.path}/tools/sdk/ld/eagle.app.v6.common.ld.h" -o "{runtime.platform.path}/tools/sdk/ld/eagle.app.v6.common.ld"

## Compile c files
recipe.c.o.pattern="{compiler.path}{compiler.c.cmd}" {compiler.cpreprocessor.flags} {compiler.c.flags} -DF_CPU={build.f_cpu} {build.lwip_flags} {build.debug_port} {build.debug_level} -DARDUINO={runtime.ide.version} -DARDUINO_{build.board} -DARDUINO_ARCH_{build.arch} -DARDUINO_BOARD="{build.board}" {build.led} {compiler.c.extra_flags} {build.extra_flags} {includes} "{source_file}" -o "{object_file}"

## Compile c++ files
recipe.cpp.o.pattern="{compiler.path}{compiler.cpp.cmd}" {compiler.cpreprocessor.flags} {compiler.cpp.flags} -DF_CPU={build.f_cpu} {build.lwip_flags} {build.debug_port} {build.debug_level} -DARDUINO={runtime.ide.version} -DARDUINO_{build.board} -DARDUINO_ARCH_{build.arch} -DARDUINO_BOARD="{build.board}" {build.led} {compiler.cpp.extra_flags} {build.extra_flags} {includes} "{source_file}" -o "{object_file}"

## Compile S files
recipe.S.o.pattern="{compiler.path}{compiler.c.cmd}" {compiler.cpreprocessor.flags} {compiler.S.flags} -DF_CPU={build.f_cpu} {build.lwip_flags} {build.debug_port} {build.debug_level} -DARDUINO={runtime.ide.version} -DARDUINO_{build.board} -DARDUINO_ARCH_{build.arch} -DARDUINO_BOARD="{build.board}" {build.led} {compiler.c.extra_flags} {build.extra_flags} {includes} "{source_file}" -o "{object_file}"

## Create archives
recipe.ar.pattern="{compiler.path}{compiler.ar.cmd}" {compiler.ar.flags} {compiler.ar.extra_flags} "{build.path}/arduino.ar" "{object_file}"

## Combine gc-sections, archives, and objects
recipe.c.combine.pattern="{compiler.path}{compiler.c.elf.cmd}" -Wl,-Map "-Wl,{build.path}/{build.project_name}.map" {compiler.c.elf.flags} {compiler.c.elf.extra_flags} -o "{build.path}/{build.project_name}.elf" -Wl,--start-group {object_files} "{build.path}/arduino.ar" {compiler.c.elf.libs} -Wl,--end-group  "-L{build.path}"

## Create eeprom
recipe.objcopy.eep.pattern=

## Create hex
#recipe.objcopy.hex.pattern="{compiler.path}{compiler.elf2hex.cmd}" {compiler.elf2hex.flags} {compiler.elf2hex.extra_flags} "{build.path}/{build.project_name}.elf" "{build.path}/{build.project_name}.hex"

recipe.objcopy.hex.pattern="{runtime.tools.esptool.path}/{compiler.esptool.cmd}" -eo "{runtime.platform.path}/bootloaders/eboot/eboot.elf" -bo "{build.path}/{build.project_name}.bin" -bm {build.flash_mode} -bf {build.flash_freq} -bz {build.flash_size} -bs .text -bp 4096 -ec -eo "{build.path}/{build.project_name}.elf" -bs .irom0.text -bs .text -bs .data -bs .rodata -bc -ec

## Save hex
recipe.output.tmp_file={build.project_name}.bin
recipe.output.save_file={build.project_name}.{build.variant}.bin

## Compute size
recipe.size.pattern="{compiler.path}{compiler.size.cmd}" -A "{build.path}/{build.project_name}.elf"
recipe.size.regex=^(?:\.irom0\.text|\.text|\.data|\.rodata|)\s+([0-9]+).*
recipe.size.regex.data=^(?:\.data|\.rodata|\.bss)\s+([0-9]+).*
#recipe.size.regex.eeprom=^(?:\.eeprom)\s+([0-9]+).*

# ------------------------------

tools.esptool.cmd=esptool
tools.esptool.cmd.windows=esptool.exe
tools.esptool.path={runtime.platform.path}/tools/esptool
tools.esptool.network_cmd=python
tools.esptool.network_cmd.windows=python.exe

tools.esptool.upload.protocol=esp
tools.esptool.upload.params.verbose=-vv
tools.esptool.upload.params.quiet=
tools.esptool.upload.pattern="{path}/{cmd}" {upload.verbose} -cd {upload.resetmethod} -cb {upload.speed} -cp "{serial.port}" {upload.erase_cmd} -ca 0x00000 -cf "{build.path}/{build.project_name}.bin"
tools.esptool.upload.network_pattern="{network_cmd}" "{runtime.platform.path}/tools/espota.py" -i "{serial.port}" -p "{network.port}" "--auth={network.password}" -f "{build.path}/{build.project_name}.bin"

tools.mkspiffs.cmd=mkspiffs
tools.mkspiffs.cmd.windows=mkspiffs.exe
tools.mkspiffs.path={runtime.platform.path}/tools/mkspiffs

لتجنب مشكلة مع platformIO قمت بحذف مجلد .pioenvs وقمت بتشغيل "Clean" على أي حال
منذ بناء هذا الصباح - تم تغيير ملفين
ESPEasy-Globals.h & Misc.ino (إصلاح تلف إعدادات المهام)

البدء في القيام بذلك: بنية المجلد الحالية الخاصة بي هي GitHub / ESpeasy
أنسخ مجلد ESpeasy وأعد تسميته لتضمين التاريخ قبل إجراء عملية الجلب ، وسيساعدني هذا في مقارنة التغييرات محليًا ..

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

@ TD-er قلت "هل لديك مهلة الإشارة التنبيهية بالرقم 0504 على أي عقدة ، أم أنها قليلة فقط؟"
حسنًا لكي نكون منصفين ، سأحصل على وحدة نمطية جديدة وفلاش في كل برنامج ثابت جديد في المستقبل.
لدي وقت لأجنيه كما هو الحال في الرابعة مساءً فقط في الجزء الذي تعيش فيه من العالم

حسنًا ، تم محو عقدة جديدة تمامًا.
تومض بـ ESP_Easy_mega-20180504_normal_ESP8266_1024.bin
السجل أدناه له نفس سلوك العقدة الأخرى ..
هل تستطيع أن ترى النمط في السجل؟

INIT : Booting version: mega-20180504 (ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3)
104 : INIT : Cold Boot
105 : FS   : Mounting...
111 : FS   : Mount successful, used 76053 bytes of 113201
408 : CRC  : program checksum       ...OK
419 : CRC  : SecuritySettings CRC   ...OK 
420 : CRC  : binary has changed since last save of Settings
439 : INIT : Free RAM:23448
440 : INIT : I2C
440 : INIT : SPI not enabled
455 : INFO : Plugins: 47 [Normal] (ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3)
455 : EVENT: System#Wake
464 : WIFI : Set WiFi to STA
mode : sta(5c:cf:7f:72:97:2a)
add if0
497 : WIFI : Connecting MAD_MOB attempt #0
498 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
STUB: dhcp_stop
511 : EVENT: System#Boot
519 : SW   : Switch state 1 Output value 1
522 : EVENT: Float_SW#Switch=1.00
536 : ACT  : Publish domoticz/in,{"idx":26,"nvalue":0,"svalue":"FLOAT_SWITCH_1_00:00:00"}
547 : Command: publish
00:23:56: 1004 : WD   : Uptime 0 ConnectFailures 0 FreeMem 22752
00:23:59: scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt 
00:24:01: 
connected with MAD_MOB, channel 7
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
5287 : WIFI : Connected! AP: MAD_MOB (18:90:D8:AC:0F:D8) Ch: 7 Duration: 4787 ms
5293 : EVENT: WiFi#ChangedAccesspoint
5304 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
5306 : WIFI : Static IP: 192.168.0.225 (ESP-Easy-0) GW: 192.168.0.254 SN: 255.255.255.0   duration: 19 ms
5324 : EVENT: WiFi#Connected
5332 : Webserver: start
5332 : WIFI  : Arduino wifi status: WL_CONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_SERVICES_INITIALIZED
5423 : MQTT : Intentional reconnect
5424 : LoadFromFile: config.dat index: 28672 datasize: 336
5500 : MQTT : Connected to broker with client ID: ESPClient_5C:CF:7F:72:97:2A
5501 : Subscribed to: domoticz/out
5502 : EVENT: MQTT#Connected
5512 : EVENT: MQTT#Connected Processing time:10 milliSeconds
5796 : NTP  : NTP host au.pool.ntp.org (27.124.125.251) queried
5867 : NTP  : NTP replied: 70 mSec
5869 : Current Time Zone:  DST time start: 2018-10-07 01:00:00 offset: 660 minSTD time start: 2018-08-05 01:00:00 offset: 600 min
5871 : EVENT: Time#Initialized
5879 : EVENT: Time#Initialized Processing time:8 milliSeconds
5881 : EVENT: Clock#Time=Sat,01:24
5887 : EVENT: Clock#Time=Sat,01:24 Processing time:6 milliSeconds
00:24:02: ping 1, timeout 0, total payload 32 bytes, 1023 ms
00:24:07: bcn_timout,ap_probe_send_start
00:24:09: pm open,type:2 0
ap_probe_send over, rest wifi status to disassoc
state: 5 -> 0 (1)
rm 0
pm close 7
14289 : EVENT: WiFi#Disconnected
14296 : WIFI : Disconnected! Reason: '(200) Beacon timeout' Connected for 9002 ms
14311 : MQTT : Connection lost
14311 : EVENT: MQTT#Disconnected
14519 : WIFI : Connecting MAD_MOB attempt #0
14520 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
00:24:11: scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt 

connected with MAD_MOB, channel 7
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
16497 : WIFI : Connected! AP: MAD_MOB (18:90:D8:AC:0F:D8) Ch: 7 Duration: 1972 ms
16499 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
16507 : WIFI : Static IP: 192.168.0.225 (ESP-Easy-0) GW: 192.168.0.254 SN: 255.255.255.0   duration: 10 ms
16527 : EVENT: WiFi#Connected
16533 : WIFI  : Arduino wifi status: WL_CONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_SERVICES_INITIALIZED
16608 : NTP  : NTP host au.pool.ntp.org (27.124.125.251) queried
00:24:12: 16679 : NTP  : NTP replied: 70 mSec
16680 : EVENT: Time#Set
16686 : EVENT: Time#Set Processing time:6 milliSeconds
16688 : LoadFromFile: config.dat index: 28672 datasize: 336
16713 : MQTT : Connected to broker with client ID: ESPClient_5C:CF:7F:72:97:2A
16714 : Subscribed to: domoticz/out
16715 : EVENT: MQTT#Connected
16724 : EVENT: MQTT#Connected Processing time:9 milliSeconds
00:24:14: ping 1, timeout 0, total payload 32 bytes, 2070 ms
00:24:18: bcn_timout,ap_probe_send_start
00:24:21: ap_probe_send over, rest wifi status to disassoc
state: 5 -> 0 (1)
rm 0
25349 : EVENT: WiFi#Disconnected
25356 : WIFI : Disconnected! Reason: '(200) Beacon timeout' Connected for 8852 ms
25371 : MQTT : Connection lost
25371 : EVENT: MQTT#Disconnected
25519 : WIFI : Connecting MAD_MOB attempt #0
25520 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt 

connected with MAD_MOB, channel 7
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
25683 : WIFI : Connected! AP: MAD_MOB (18:90:D8:AC:0F:D8) Ch: 7 Duration: 158 ms
25686 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
25694 : WIFI : Static IP: 192.168.0.225 (ESP-Easy-0) GW: 192.168.0.254 SN: 255.255.255.0   duration: 11 ms
25714 : EVENT: WiFi#Connected
25721 : WIFI  : Arduino wifi status: WL_CONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_SERVICES_INITIALIZED
25815 : LoadFromFile: config.dat index: 28672 datasize: 336
25836 : MQTT : Connected to broker with client ID: ESPClient_5C:CF:7F:72:97:2A
25838 : Subscribed to: domoticz/out
25838 : EVENT: MQTT#Connected
25845 : EVENT: MQTT#Connected Processing time:7 milliSeconds
00:24:22: 26585 : NTP  : NTP host au.pool.ntp.org (27.124.125.251) queried
26656 : NTP  : NTP replied: 70 mSec
26657 : EVENT: Time#Set
26663 : EVENT: Time#Set Processing time:6 milliSeconds
ping 1, timeout 0, total payload 32 bytes, 1010 ms
00:24:26: 31005 : WD   : Uptime 1 ConnectFailures 4 FreeMem 19304
00:24:28: bcn_timout,ap_probe_send_start
00:24:30: ap_probe_send over, rest wifi status to disassoc
state: 5 -> 0 (1)
rm 0
35077 : EVENT: WiFi#Disconnected
35083 : WIFI : Disconnected! Reason: '(200) Beacon timeout' Connected for 9394 ms
35094 : MQTT : Connection lost
35095 : EVENT: MQTT#Disconnected
35519 : WIFI : Connecting MAD_MOB attempt #0
35520 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt 

connected with MAD_MOB, channel 7
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
35685 : WIFI : Connected! AP: MAD_MOB (18:90:D8:AC:0F:D8) Ch: 7 Duration: 160 ms
35687 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
35696 : WIFI : Static IP: 192.168.0.225 (ESP-Easy-0) GW: 192.168.0.254 SN: 255.255.255.0   duration: 11 ms
35715 : EVENT: WiFi#Connected
35721 : WIFI  : Arduino wifi status: WL_CONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_SERVICES_INITIALIZED
35816 : LoadFromFile: config.dat index: 28672 datasize: 336
35844 : MQTT : Connected to broker with client ID: ESPClient_5C:CF:7F:72:97:2A
35845 : Subscribed to: domoticz/out
35846 : EVENT: MQTT#Connected
35855 : EVENT: MQTT#Connected Processing time:9 milliSeconds
00:24:32: 36735 : NTP  : NTP host au.pool.ntp.org (144.48.166.166) queried
ping 1, timeout 0, total payload 32 bytes, 1016 ms
37739 : NTP  : No reply
00:24:39: bcn_timout,ap_probe_send_start
00:24:41: pm open,type:2 0
ap_probe_send over, rest wifi status to disassoc
state: 5 -> 0 (1)
rm 0
pm close 7
46238 : EVENT: WiFi#Disconnected
46244 : WIFI : Disconnected! Reason: '(200) Beacon timeout' Connected for 10 s
46260 : MQTT : Connection lost
46261 : EVENT: MQTT#Disconnected
46519 : WIFI : Connecting MAD_MOB attempt #0
46520 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt 
00:24:42: 
connected with MAD_MOB, channel 7
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
46679 : WIFI : Connected! AP: MAD_MOB (18:90:D8:AC:0F:D8) Ch: 7 Duration: 154 ms
46681 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
46689 : WIFI : Static IP: 192.168.0.225 (ESP-Easy-0) GW: 192.168.0.254 SN: 255.255.255.0   duration: 10 ms
46709 : EVENT: WiFi#Connected
46715 : WIFI  : Arduino wifi status: WL_CONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_SERVICES_INITIALIZED
46809 : LoadFromFile: config.dat index: 28672 datasize: 336
46843 : MQTT : Connected to broker with client ID: ESPClient_5C:CF:7F:72:97:2A
46844 : Subscribed to: domoticz/out
46845 : EVENT: MQTT#Connected
46851 : EVENT: MQTT#Connected Processing time:6 milliSeconds

آه أعتقد أن الوقت قد حان لإعداد نقطة وصول خاصة لتشغيل wireshark

باستخدام GitHub Desktop ، أحضرت أحدث مصدر "مباشر" والذي يتضمن فقط ملفين تم تغييرهما من https://github.com/letscontrolit/ESPEasy/commit/92680c5542b76a15db16af198a3a07ed17618c4e منذ تجميع عملي من هذا الصباح ، وجعلت نسخة مسائية وتعمل بشكل مثالي ..
لماذا تختلف الإنشاءات الليلية إذا كانت هي نفس المصدر ، فما الذي يحدث بشكل مختلف على GitHub؟

أي شخص يستخدم Arduino IDE؟
هل أنت قادر على بناء "1024 عادي ESP8266" من src الحالية وتفريغها هنا؟
شكرا

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

ما هو إصدار البناء هذا؟

تضمين التغريدة

لماذا تختلف الإنشاءات الليلية إذا كانت هي نفس المصدر ، فما الذي يحدث بشكل مختلف على GitHub؟

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

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

تجميعها الذاتي من ميجا 20180503
بناء | 20102 - ميجا
مكتبات | ESP82xx Core 76a14b1f و NONOS SDK 2.2.1 (cfd48f3) و LWIP: 2.0.3

هل يمكنك محاولة بنائه مرتين قبل كتابته في العقدة؟
لا يوجد تنظيف بين البنيات ، فقط قم ببنائها والبناء مرة أخرى.

بالتأكيد ، لكنني أستخدم Arduino SDK على جهاز Mac ، وليس platformIO ... ما زلت أستخدم Arduino SDK؟

نعم من فضلك افعل ، لأننا لا نملك أدنى فكرة حتى الآن عن سبب ذلك.
فقط تأكد من أنك تستخدم نفس المكتبات الأساسية التي نستخدمها ، لأن Arduino IDE لا ينظر إلى الإصدارات الثابتة المحددة في PlatformIO.
الإصدارات الحالية التي نستخدمها هي:
ESP82xx Core 2_4_1 و NONOS SDK 2.2.1 (cfd48f3) و LWIP: 2.0.3

حسنًا ، سأحاول ذلك الآن وأومض بعض الوحدات. سأبلغ بمجرد حدوث شيء ما ... أو لا شيء على الإطلاق ؛)

بالمناسبة. يمكن أن يتعطل الإصدار الحالي في أي وقت عن طريق الضغط باستمرار على F5 في متصفح الويب على الأقل على صفحات الجهاز أو الإشعارات (ربما على أي صفحة ويب ESP) لبضع ثوان. يمكنني تكراره في أي وقت من Firefox على Win10:
...
...
39543696: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك النواة: 0
39551825: LoadFromFile: config.dat index: 27648 datasize: 320
39557599: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك النواة: 0
39566681: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك Core: 0
39566879: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك Core: 0
39567105: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك Core: 0
39567490: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك Core: 0
39567690: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك Core: 0
39567883: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك Core: 0
39568086: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك النواة: 0
39568287: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك Core: 0
39568495: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك Core: 0
39568701: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك Core: 0
39568910: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك النواة: 0
39569112: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك Core: 0
39569324: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك Core: 0
39569530: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك النواة: 0
39569739: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك النواة: 0
39569948: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك النواة: 0
39570158: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك Core: 0
39570366: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك Core: 0
39570582: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك Core: 0
39570742: تم تخطي صفحة الويب: انخفاض الذاكرة: 1784
39570832: تم تخطي صفحة الويب: انخفاض الذاكرة: 1784
39570906: تم تخطي صفحة الويب: انخفاض الذاكرة: 1784
39570992: تم تخطي صفحة الويب: انخفاض الذاكرة: 1784
39571074: تم تخطي صفحة الويب: انخفاض الذاكرة: 1784
39571161: تم تخطي صفحة الويب: انخفاض الذاكرة: 1784
39571240: تم تخطي صفحة الويب: انخفاض الذاكرة: 1784
39571322: تم تخطي صفحة الويب: انخفاض الذاكرة: 1784
39571401: تم تخطي صفحة الويب: انخفاض الذاكرة: 1784

استثناء (28):
epc1 = 0x4025cb66 epc2 = 0x00000000 epc3 = 0x401003f2 excvaddr = 0x00000000 depc = 0x00000000

ctx: تابع
sp: 3fff4690 النهاية: 3fff4b20 الإزاحة: 01a0

كومة >>>
3fff4830: 00000000 3ffe90c0 3fff48a4 40253308
3fff4840: 00000000 3ffe90c0 3fff48d4 40257c32
3fff4850: 00000000 3ffe90c0 00000043 4021ada8
3fff4860: 00000000 00000000 00000000 000006c0
3fff4870: 000006f8 00000000 00000000 00000000
3fff4880: 00000000 00000000 00000000 40107b18
3fff4890: 00000000 000003e8 3fff48f0 00000000
3fff48a0: 00000000 00000000 00000000 00000000
3fff48b0: 4029cdfc 00000007 3fff48f0 3fffbfdc
3fff48c0: 0000000f 0000000b 3fff815c 0000000f
3fff48d0: 00000000 3fffb8a4 0000025f 0000025c
3fff48e0: 00000001 3fff16d4 3fff6294 40227cb4
3fff48f0: 3fffb414 0000000f 00000007 4010053d
3fff4900: 3fff4d6c 00000855 00000855 3fff4d6c
3fff4910: 00000010 00000010 00000000 3fff36d4
3fff4920: 00000010 3fff5d14 3fff5d14 40257a6f
3fff4930: 3ffe8ea1 00000000 3fff5d14 40257abb
3fff4940: 00000000 00000010 3fff5d14 3fff4d6c
3fff4950: 40107b70 ffffffff 00000000 40253308
3fff4960: 3fff3a14 00000001 3fff6294 4022fc8d
3fff4970: 00000010 3fff49e0 3ffe8ea1 40207ae8
3fff4980: 00000000 3fff49e0 3fff1868 4028577b
3fff4990: 4025653c 00000001 3fff1868 40253308
3fff49a0: 3fff4d6c 00000c35 00000c35 4010020c
3fff49b0: 00000001 00000001 3fff49e0 40107b70
3fff49c0: ffffffff 40107b70 00000000 40257a14
3fff49d0: 4020a8ca 00000001 3fff6294 4022fd96
3fff49e0: 00000000 00000000 00000000 40253308
3fff49f0: 00000001 00000001 3fff6294 4022fe80
3fff4a00: 00000001 00000001 3fff4a30 40259cfa
3fff4a10: 3fff4d6c 00000112 3fff6294 402532fe
3fff4a20: 3fff6294 3fff366c 3fff6294 4025333a
3fff4a30: 00000000 00000000 00000000 40257c18
3fff4a40: 3fff6294 3fff366c 3fff3628 402533c1
3fff4a50: 3fff5afc 0000000f 00000008 00000000
3fff4a60: 00000000 3fff4ab0 3fff362c 4024ca28
3fff4a70: 3fff366c 00000001 00000000 4024d200
3fff4a80: 00000001 00000000 40251b18 0000000d
3fff4a90: 00000000 3fff7b4c 3fff3628 3fff3af4
3fff4aa0: 00000001 3fff3650 3fff3628 40253618
3fff4ab0: 40107910 00000000 00001388 3fff3b00
3fff4ac0: 00000000 3fff7b4c 00000000 40256abd
3fff4ad0: 3fffdad0 00000000 3fff1944 4023742a
3fff4ae0: 3fffdad0 00000000 3fff19c4 40240380
3fff4af0: 00000000 00000000 00000001 40258a31
3fff4b00: 3fffdad0 00000000 3fff3aee 40258a5c
3fff4b10: feefeffe 3fff3b00 40100700
<<

8 كانون الثاني (يناير) 2013 ، السبب الأول

تحميل 0x4010f000 ، لين 1384 ، غرفة 16
الذيل 8
chksum 0x2d
كسوم 0x2d
v614f7c32
~ لد
U88:

تهيئة: إصدار التمهيد: mega-20180504 (ESP82xx Core 2_4_1 ، NONOS SDK 2.2.1 (cfd48f3) ، LWIP: 2.0.3)
89: تهيئة: التمهيد الدافئ # 3
90: خ م: تركيب ...
115: FS: تم التحميل بنجاح ، تم استخدام 75802 بايت من 957314
437: اتفاقية حقوق الطفل: المجموع الاختباري للبرنامج ... حسنًا
469: اتفاقية حقوق الطفل: إعدادات الأمان اتفاقية حقوق الطفل ... حسنًا
575: تهيئة: ذاكرة RAM مجانية
575: تهيئة: I2C
575: تهيئة: SPI غير ممكّن
1677: INFO: المكونات الإضافية: 72 [عادي] [اختبار] [تطوير] (ESP82xx Core 2_4_1 ، NONOS SDK 2.2.1 (cfd48f3) ، LWIP: 2.0.3)
1678: حدث: استيقظ النظام #
1682: WIFI: اضبط WiFi على STA
...
...

ثم تم توصيل الجهاز بـ AP بنجاح. حادث آخر:

973: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك النواة: 0
279178: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك النواة: 0
279387: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك النواة: 0
279590: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك النواة: 0
279798: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك النواة: 0
280321: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك النواة: 0
280558: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك النواة: 0
280785: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك النواة: 0
الاستثناء الفادح 28 (LoadProhibitedCause):
epc1 = 0x4025cb66 ، epc2 = 0x00000000 ، epc3 = 0x40100408 ، excvaddr = 0x00000000 ، depc = 0x00000000

استثناء (28):
epc1 = 0x4025cb66 epc2 = 0x00000000 epc3 = 0x40100408 excvaddr = 0x00000000 depc = 0x00000000

ctx: تابع
sp: 3fff4690 النهاية: 3fff4b20 الإزاحة: 01a0

كومة >>>
3fff4830: 00000000 3ffe90c0 3fff48a4 40253308
3fff4840: 00000000 3ffe90c0 3fff48d4 40257c32
3fff4850: 00000000 3ffe90c0 0000002f 4021ada8
3fff4860: 00000000 00000000 00000000 000007e8
3fff4870: 00000820 00000000 00000000 00000000
3fff4880: 00000000 00000000 00000000 40107b18
3fff4890: 00000000 000003e8 3fff48f0 00000000
3fff48a0: 00000000 00000000 00000000 00000000
3fff48b0: 4029cdfc 00000007 3fff48f0 3fff9af4
3fff48c0: 0000000f 0000000b 3fff9adc 0000000f
3fff48d0: 00000004 3fffb7bc 0000025f 00000130
3fff48e0: 00000001 3fff16d4 3fff773c 40227cb4
3fff48f0: 3fff83ac 0000000f 00000007 4010053d
3fff4900: 3fff4d6c 00000a67 00000a67 3fff4d6c
3fff4910: 00000010 00000010 00000000 3fff36d4
3fff4920: 00000010 3fff9014 3fff9014 40257a6f
3fff4930: 3ffe8ea1 00000000 3fff9014 40257abb
3fff4940: 00000000 00000010 3fff9014 3fff4d6c
3fff4950: 40107b70 ffffffff 00000000 40253308
3fff4960: 3fff3a14 00000001 3fff773c 4022fc8d
3fff4970: 00000010 3fff49e0 3ffe8ea1 40207ae8
3fff4980: 00000000 3fff49e0 3fff185c 4028577b
3fff4990: 4025653c 00000001 3fff185c 40253308
3fff49a0: 3fff4d6c 00000628 00000628 4010020c
3fff49b0: 00000001 00000001 3fff49e0 40107b70
3fff49c0: ffffffff 40107b70 00000000 40257a14
3fff49d0: 4020a8ca 00000001 3fff773c 4022fd96
3fff49e0: 00000000 00000000 00000000 40253308
3fff49f0: 00000001 00000001 3fff773c 4022fe80
3fff4a00: 00000001 00000001 3fff4a30 40259cfa
3fff4a10: 00000000 00000000 3fff773c 402532fe
3fff4a20: 3fff773c 3fff366c 3fff773c 4025333a
3fff4a30: 00000000 00000000 00000000 40257c18
3fff4a40: 3fff773c 3fff366c 3fff3628 402533c1
3fff4a50: 3fff9594 0000000f 00000008 00000000
3fff4a60: 00000000 00000000 3fff362c 4024ca28
3fff4a70: 3fff366c 00000001 00000000 4024d200
3fff4a80: 00000001 00000000 40251b18 0000000d
3fff4a90: 00000000 3fff9b0c 3fff3628 3fff3af4
3fff4aa0: 00000001 3fff3650 3fff3628 40253618
3fff4ab0: 40107910 00000000 00001388 3fff3b00
3fff4ac0: 00000000 3fff9b0c 00000000 40256abd
3fff4ad0: 3fffdad0 00000000 3fff1944 4023742a
3fff4ae0: 3fffdad0 00000000 3fff19c4 40240380
3fff4af0: 00000000 00000000 00000001 40258a31
3fff4b00: 3fffdad0 00000000 3fff3aee 40258a5c
3fff4b10: feefeffe 3fff3b00 40100700
<<

8 كانون الثاني (يناير) 2013 ، السبب الأول

تحميل 0x4010f000 ، لين 1384 ، غرفة 16
الذيل 8
chksum 0x2d
كسوم 0x2d
v614f7c32
~ لد
U89:

تهيئة: إصدار التمهيد: mega-20180504 (ESP82xx Core 2_4_1 ، NONOS SDK 2.2.1 (cfd48f3) ، LWIP: 2.0.3)
89: تهيئة: التمهيد الدافئ # 8
91: ف.ش .: تصاعد ...
116: FS: تم التحميل بنجاح ، تم استخدام 75802 بايت من 957314
438: اتفاقية حقوق الطفل: المجموع الاختباري للبرنامج ... حسنًا
469: اتفاقية حقوق الطفل: إعدادات الأمان اتفاقية حقوق الطفل ... حسنًا
575: تهيئة: ذاكرة RAM مجانية
576: تهيئة: I2C
576: تهيئة: SPI غير ممكّن
1678: INFO: المكونات الإضافية: 72 [عادي] [اختبار] [تطوير] (ESP82xx Core 2_4_1 ، NONOS SDK 2.2.1 (cfd48f3) ، LWIP: 2.0.3)
1678: حدث: استيقظ النظام #
1683: WIFI: اضبط WiFi على STA
...

حسنًا ، هذا مع 72 ملحقًا ، ماذا عن العادي الذي يتصرف بنفس الطريقة ؛)

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

على الأقل ، من الجيد أن يكون قابلاً للاسترداد - التعليق الكامل سيكون أسوأ من إعادة التشغيل ... لكن من الغريب أن سبب التمهيد لم يكن كما هو في كل مرة - رأيت أيضًا سبب 4.

ESP_Easy_mega-20180504_test_ESP8266_1024.bin
يمكنني الحصول على wifi للاتصال (المحاولة الأولى) والبقاء على اتصال
F5 (صفحة الأجهزة) لا تسبب أخطاء أو تعطل
ESP_Easy_mega-20180504_normal_ESP8266_1024.bin
يربط ويفشل في دورة 11 ثانية أكثر وأكثر - (200) مهلة منارة
ESP_Easy_mega-20180504_normal_ESP8266_1024_ (Self_Compiled) .bin
في احسن الاحوال

Oxyandy بطيئة لوحة المفاتيح
تعطل منجم في كل صفحة ويب حاولت.

ghtester سأقوم ببناء مجموعة على جهاز الكمبيوتر الخاص بي ، مع جميع التعليمات البرمجية الحالية. سيستغرق البناء حوالي 30 دقيقة.

@ TD-er شكرًا جزيلاً لجهودك ، سأختبرها عندما يصبح التصميم الجديد جاهزًا.

@ TD-er تومض وحداتي (16) الآن مع ESP82xx Core 2_4_1 ، NONOS SDK 2.2.1 (cfd48f3) ، LWIP: 2.0.3 مبني مرتين قبل الوميض ... سأرى غدًا ما إذا كانوا لا يزالون على قيد الحياة ويرسلون البيانات ... اضطررت إلى استخدام النطاق الترددي العالي lwIP2 وإلا فسيتم اقتطاع البيانات المرسلة عبر وحدة التحكم FHEM!
لكن بحاجة للنوم الآن .... n8

انتبه إلى مشكلات HTTP POST مع إصدار النطاق الترددي العالي.

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

شاهد البناء: https://github.com/letscontrolit/ESPEasy/releases/tag/mega-20180505_TD-er

TD-er ، جهازك ، أجهزتي ، لا توجد مشكلة مع (عادي 1024 8266)
انتظار الإصدار اليومي للعرض سيحاول ذلك بعد ذلك ؛)

@ TD-er شكرًا جزيلاً ، تم اختبار إصدار 4096 dev سريعًا (للمتابعة) ، ولا تزال مشكلة إعادة التشغيل "F5" قائمة (المحاولة الأولى علقت الجهاز تمامًا) وتشير معلومات البرامج الثابتة إلى فشل فحص MD5 (أفترض أنه بسبب بناء الاختبار). ومع ذلك ، كل شيء آخر على ما يرام حتى الآن وهو متصل بشكل مثالي وسريع بـ AP.

بناء 20102 - ميجا
مكتبات ESP82xx Core 2_4_1 و NONOS SDK 2.2.1 (cfd48f3) و LWIP: 2.0.3
نسخة GIT
الإضافات 72 [عادي] [اختبار] [تطوير]
بناء Md5 4d44355f4d44355f4d44355f4d44355f
فشل فحص Md5!
وقت البناء 5 مايو 2018 00:33:21
اسم الملف الثنائي ThisIsTheDummyPlaceHolderForTheBinaryFilename ...

كما تم إنشاؤه وإصداره على GitHub ، كلا هذين الرقمين BIN ، يوم واحد (1 Build) منفصلين.
ESP_Easy_mega-20180504_normal_ESP8266_1024.bin
تم تأكيد وجود "خلل" في العديد من الطرق المختلفة ، إعادة الضبط ، العقد المختلفة ، إلخ
المشاكل المتسقة (201 Beacon Timeout) في حلقة مدتها 11 ثانية
البيرة تعمل بشكل مثالي من نفس المصدر.
ل
ESP_Easy_mega-20180505_normal_ESP8266_1024.bin
العمل بشكل مثالي ، التغييرات في المصدر ضئيلة
أخبرني ، أن إصدارات GitHub بها فشل "في مكان ما" في التجميع ..
الاتصال بشبكة Wifi أولاً ، تحديث فوري للوقت ، عدم إسقاط Wifi مرة واحدة ،
MQTT الحفاظ على الاتصال
إلخ إلخ -
لا شيء يخطئ؛)

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

بالنسبة لمسألة f5: جرب lwip عرض النطاق الترددي العالي لأنه يحتوي على مخازن أكبر. قد يتعطل بعد ذلك بقليل.

تجميع المشكلات: أنت تعمل بسرعة 80 ميجا هرتز ، أليس كذلك؟

80 ميغا هرتز هو الافتراضي على ما أعتقد.

أنا أعرف. لكن ضبطه على 160 قد يسبب سلوكًا غريبًا.

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

18084332: الحدث: الساعة # الوقت = السبت ، 08:47 وقت المعالجة
18091174: WD: Uptime 302 ConnectFailures 0 FreeMem 14504
bcn_timout ، ap_probe_send_start
18112119: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك Core: 0
18115167: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك Core: 0
18116976: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك Core: 0
18119084: LoadFromFile: alert.dat index: 0 datasize: 996
18119089: LoadFromFile: alert.dat index: 1024 حجم البيانات: 996
18119092: LoadFromFile: alert.dat index: 2048 datasize: 996
18119129: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك Core: 0
18121330: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك النواة: 0
18121337: WD: Uptime 302 ConnectFailures 0 FreeMem 13584
18128862: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك النواة: 0
18130833: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك النواة: 0
18135120: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك النواة: 0
18136605: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك النواة: 0
18138356: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك Core: 0
18140067: LoadFromFile: alert.dat index: 0 datasize: 996
18140076: LoadFromFile: alert.dat index: 1024 حجم البيانات: 996
18140078: LoadFromFile: alert.dat index: 2048 datasize: 996
18140152: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك النواة: 0
18144694: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك النواة: 0
18144700: الحدث: الساعة # الوقت = السبت ، 08:48
18144702: الحدث: الساعة # الوقت = السبت ، 48:48 وقت المعالجة
18148558: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك Core: 0
18151336: WD: Uptime 303 ConnectFailures 0 FreeMem 12568
18153230: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك النواة: 0
18153763: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك النواة: 0
18155000: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك النواة: 0
18155592: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك النواة: 0
18156416: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك النواة: 0
18156838: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك النواة: 0
18164949: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك النواة: 0
18165234: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك النواة: 0
18165587: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك النواة: 0
18170770: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك Core: 0
18170947: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك Core: 0
18171120: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك النواة: 0
18171300: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك النواة: 0
18171733: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك النواة: 0
18177686: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك Core: 0
bcn_timout ، ap_probe_send_start
18181336: WD: Uptime 303 ConnectFailures 0 FreeMem 10832
18182865: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك النواة: 0
18183367: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك النواة: 0
18188878: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك النواة: 0
18190025: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك النواة: 0
18203237: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك النواة: 0
18203809: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك النواة: 0
18203817: الحدث: الساعة # الوقت = السبت ، 08:49
18203819: الحدث: الساعة # الوقت = السبت ، 08:49 وقت المعالجة
bcn_timout ، ap_probe_send_start
bcn_timout ، ap_probe_send_start
bcn_timout ، ap_probe_send_start
18496844: استخدام ذاكرة الوصول العشوائي: خادم الويب فقط: 0 بما في ذلك Core: 0
18496850: WD: Uptime 304 ConnectFailures 0 FreeMem 8736
18496856: الحدث: الساعة # الوقت = السبت ، 08:53
18496858: الحدث: الساعة # الوقت = السبت ، 08:53 زمن المعالجة

بعد آخر ثلاث رسائل bcn_timout ، ap_probe_send_start ، تم تجميد الجهاز لمدة 60 ثانية تقريبًا حتى في وحدة التحكم التسلسلية ، ثم استمر في العمل دون إعادة تشغيل.

نعم إنه يعمل بسرعة 80 ميجاهرتز - معلومات النظام تقول: ESP Chip Freq: 80 MHz

استجابات الويب الخاصة بـ ESP سريعة جدًا حتى أحاول التحديث بسرعة كبيرة ...

صباح كل شيء ... تعمل وحداتي مستقرة لمدة 10 ساعات تقريبًا الآن. ومع ذلك ، ظهرت المشكلات في بعض الأحيان بعد يوم أو يومين فقط ، لذلك أتركها تعمل على هذا النحو. أعد تشغيل وحدة واحدة مرتين أثناء الليل (من بين 16 D1) والتي يمكن أن تكون مرتبطة بالمكوِّن الإضافي أو نحو ذلك ... تعمل أساسيات Sonoff أيضًا بسلاسة.

أعلم أنك لا تستطيع رؤية أو شرح TD-er ، لكن هل استخدمت تصميمات GitHub كاختبار؟
قد أعود إلى مصدر الإصدارات في الشهر الماضي وأقارنها مع البيرة المنزلية
لقد كان لدي الكثير الذي اعتبرته عديم الفائدة ، إحدى علامات التبويب الخاصة بي في Notepad ++ بها القائمة

حول F5 ، ليست مشكلة حقًا - أستخدمها كمعيار ، وليس لدي تحديث تلقائي لمفتاح F5 ،
لذلك أنا أضربها يدويًا ، وأراقب استخدام ذاكرة الوصول العشوائي وإخراج السجل التسلسلي في نفس الوقت ..
"النطاق الترددي العالي lwip" من الذاكرة كان شبه فوري
أخطاء LmacRxBlk:1 ولم تكن قابلة للاسترداد ..
وهو ما يذكرني بأنني من المفترض أن أكتب شيئًا عن .. في قائمة المهام ..
وسأحاول إعدادات ترجمة مختلفة مرة أخرى كإجراء

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

1127917: WIFI: خطأ أثناء بدء وضع AP مع SSID: ESP_01_1 IP: 192.168.4.1

لكن الجهاز كان مرئيًا كـ AI-THINKER_XXXXXXX ، تمكنت من توصيله ولكن عندما حاولت تغيير اسم الجهاز وما إلى ذلك ، عانيت من فقدان الاتصال بالجهاز وتعطل وإعادة التشغيل وما إلى ذلك ... :-(

تحديث - بعد عدة محاولات ، أعدت تسمية الجهاز لإزالة التسطير ، ولكن لا يزال هناك رقم قبل الجهاز:
599417: WIFI: خطأ أثناء بدء وضع AP مع SSID: ESP-001_1 IP: 192.168.4.1
والجهاز لا يزال مرئيًا كـ AI-THINKER_XXXXXXX
لا يمكنني الاتصال بـ AP كعميل بعد الآن ... سأحاول إعادة ضبط إعدادات المصنع ...

تحديث 2 موافق ... إعادة ضبط المصنع ، يظهر الجهاز كـ ESP_Easy_0 AP ... اضبط WifiSSID و WifiKey من خلال وحدة التحكم التسلسلية ، الجهاز متصل على الفور بـ AP ...

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

هناك شيء آخر سأجربه الآن هو بدلاً من تحديد لوحة "D1 Mini" في اردوينو ، قمت بتعيين جميع المعلمات بنفسي واستخدام الوحدة "العامة 8266" ... سنرى ما إذا كان هذا يحدث فرقًا ...

الشيء الوحيد الذي أراه حاليًا هو بعض عمليات إعادة التشغيل التلقائية من وحدات معينة ... ولكن هذا قد يكون مرتبطًا بأشياء أخرى ...

سؤال واحد مني: sonoff basic لديها ذاكرة 1M فقط ... هل هناك فرصة لتحديث هذه الأشياء عبر OTA؟ من الواضح دائمًا أنها تدعي "لا توجد ذاكرة كافية" ... أية أفكار؟

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

يمكنك استخدام مكونات إضافية أقل عند التجميع. انظر إلى https://github.com/letscontrolit/ESPEasy/blob/mega/src/define_plugin_sets.h

لن تتمكن أبدًا من OTA مباشرة ، ولكن بهذه الطريقة تكون صغيرة بما يكفي لـ OTA على مرحلتين. انظر إلى الويكي لذلك :)

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

500 كيلو صغيرة بما يكفي. كما قلت ، جزئين OTA. لا يمكنك التحديث مباشرة. انظر إلى ويكي :)

thx .. بحث ....؛)

أضف: بطريقة ما فاتني الجزء المكون من خطوتين ....

مع 1M Sonoffs ، ستحتاج إلى استخدام برنامج التحميل الأولي الذي يحتوي على علامة DOUT في العنوان ،
من الذاكرة الشخص الموجود في الويكي ليس كذلك ، ولكن ربما تم تحديثه مؤخرًا ..

أتذكر شيئًا من هذا القبيل ، لقد بحثت للتو عن أنا أستخدم هذا لـ OTA: https://github.com/soif/EspBuddy/blob/master/firmwares/ESPEasyUploader.OTA.1m128.esp8266.bin

نعم ، التحقق من أن DOUT
ها هي واحدة قمت بتجميعها وهي أصغر
Initial_Firmware_Uploader_Sonoff_1M_DOUT.zip

قلت إنني سأفعل ذلك لأنني كنت فضوليًا جدًا ........
بالمقارنة مع Self_Compiled mega-20180422 إلى GitHub الذي تم إصداره ، حتى الآن - جربت واحدًا فقط
ESP_Easy_mega-20180422_normal_ESP8266_1024.bin
لقد تركت تعليقًا وقمت بتسجيل الدخول إلى سلوكه هنا https://github.com/letscontrolit/ESPEasy/issues/1301#issuecomment -383433822 (تم إصدار GitHub)
المصدر نفسه تجميعه ذاتيًا ، ليس من المستغرب ، أرى سلوكًا مختلفًا عن Nightly.
بقي على اتصال ، صدمة الرعب!
أصدر GitHub ميجا 20180422 ، يومض فوق القمة ، وهو نفس السلوك الذي أبلغت عنه بالضبط عندما جربته لأول مرة.
لن تبقى على اتصال ، WIFI : Disconnected! Reason: '(200) Beacon timeout' ركوب الدراجات مرارًا وتكرارًا
السبب يحتاج إلى التحقيق ... تنهد
تم إصدار جيثب = لا يمكن الوثوق به؟

لقد قمت بنشر أعلام مترجم Arduino بالأمس أو نحو ذلك. ما هي العلامات التي يستخدمها ترافيس؟

لدي 16 D1's و 3 basic تعمل على f69e476 ذاتي التجميع ، Core 2.4.1 ، lwIP2 High bandwith.
تقريبا كل منهم مع وقت تشغيل> 900 دقيقة. الآن وما زلت تعمل بشكل جيد. تحول اثنان منهم إلى وضع AP منذ حوالي ساعة ولم يعودا الاتصال حتى الآن. سأنتظر حتى الليلة وأرى ما إذا كانوا يتعافون.

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

Oxyandy : لقد قمت أيضًا لأعمالي الأساسية بشكل جيد! شكرا مرة أخرى لتوجيهي إلى الاتجاه الصحيح ..؛)

@ s0170071
يتم تخزينها في .travis.yml & platformio.ini
سرعت في القراءة ، تادا ، انظر ماذا وجدت
skip_cleanup: true
تحرير: مزيد من القراءة لست متأكدًا مما إذا كان هذا يشير إلى إنشاء بنية نظيفة ؟
أعترف أن كل شيء جديد بالنسبة لي ... ؟؟؟ تعطيل التخزين المؤقت؟

يقوم Travis ببناء نظيف في كل مرة ، لأنه يقوم بتنزيل بيئة python ، إلخ.

تم تنفيذ الإنشاءات الليلية بواسطة

Okee dokee ، فهل هم نظيفون؟
تحاول أن تفهم لماذا يتصرفون بشكل مختلف؟

ماذا عن مقارنة MD5 بين bin1 و bin2؟
سيشير إلى ما إذا كانت مشكلة في وقت التشغيل أو وقت التشغيل ...

susisstrolch تقصد عندما تجمع نفسك؟ لأنه يتم حساب MD5 بعد التجميع. هناك نص يقوم بذلك نيابة عنك.
https://github.com/s0170071/CRC4ESP

-تعديل: susisstrolch ربما
نعم ، يمكنك مقارنة md5 ، يجب أن تكون متطابقة. إذا قمت بذلك في وضع عدم الاتصال ، فيمكنك أيضًا مقارنة الثنائيات قليلاً. بهذه الطريقة يمكنك حتى معرفة مكان الانحراف. إذا كنت متقدمًا ، يمكنك حتى إرجاع ذلك إلى الكود. يجب أن يحتوي ملف .elf على جميع المعلومات.

على أي حال ، لا أهتم كثيرًا بما يختلف تمامًا. أعتقد أنه من الأهمية بمكان التأكد من أنهم جميعًا على نفس النظام الثنائي - بغض النظر عمن قام بتجميعها.

إذن مرة أخرى ، ما هي أعلام التجميع الخاصة بـ Arduino و Platformio و Nightly و travis؟ وين / لينكس.

لا - أعني بدلاً من التكهن بالاختلافات في إخراج المترجم في الإنشاءات الآلية ، ببساطة قارن MD5 لكلا البناءين. لذلك يمكنك معرفة ما إذا كانت تختلف بالضبط.

أعلام Arduino IDE على نظام Linux هي:

build.lwip_lib=-llwip_gcc
build.lwip_include=lwip/include
build.lwip_flags=-DLWIP_OPEN_SRC
build.vtable_flags=-DVTABLES_IN_FLASH
build.float=-u _printf_float -u _scanf_float


compiler.cpreprocessor.flags=-D__ets__ -DICACHE_FLASH -U__STRICT_ANSI__ "-I{compiler.sdk.path}/include" "-I{compiler.sdk.path}/{build.lwip_include}" "-I{compiler.libc.path}/include" "-I{build.path}/core"

compiler.c.cmd=xtensa-lx106-elf-gcc
compiler.c.flags=-c {compiler.warning_flags} -Os -g -Wpointer-arith -Wno-implicit-function-declaration -Wl,-EL -fno-inline-functions -nostdlib -mlongcalls -mtext-section-literals -falign-functions=4 -MMD -std=gnu99 -ffunction-sections -fdata-sections

compiler.S.cmd=xtensa-lx106-elf-gcc
compiler.S.flags=-c -g -x assembler-with-cpp -MMD -mlongcalls

compiler.c.elf.flags=-g {compiler.warning_flags} -Os -nostdlib -Wl,--no-check-sections -u app_entry {build.float} -Wl,-static "-L{compiler.sdk.path}/lib" "-L{compiler.sdk.path}/ld" "-L{compiler.libc.path}/lib" "-T{build.flash_ld}" -Wl,--gc-sections -Wl,-wrap,system_restart_local -Wl,-wrap,spi_flash_read

compiler.c.elf.cmd=xtensa-lx106-elf-gcc
compiler.c.elf.libs=-lhal -lphy -lpp -lnet80211 {build.lwip_lib} -lwpa -lcrypto -lmain -lwps -laxtls -lespnow -lsmartconfig -lairkiss -lwpa2 -lstdc++ -lm -lc -lgcc

compiler.cpp.cmd=xtensa-lx106-elf-g++
compiler.cpp.flags=-c {compiler.warning_flags} -Os -g -mlongcalls -mtext-section-literals -fno-exceptions -fno-rtti -falign-functions=4 -std=c++11 -MMD -ffunction-sections -fdata-sections

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

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

@ s0170071 لذلك نحصل على الكثير من معلومات التصحيح بسبب الخيار -g عند البناء باستخدام Arduino IDE.
ربما نقطة لتقليل الحجم ...

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

تعافى الاثنان بعد بضع ساعات خلال النهار ، لكن البعض الآخر فشل بشكل عشوائي ... شيئان وجدتهما حتى الآن:
أحصل على إدخالات في السجل تقول:
96493069: IP محظور: 0.0.0.0 مسموح به: 10.0.0.0 - 10.0.255.255
96517068: WD: Uptime 1608 ConnectFailures 0 FreeMem 11544
السطر الأول يبدو غريبًا بالنسبة لي ، ما الذي يحاول الاتصال بـ IP 0.0.0.0؟ قد يكون هذا متعلقًا بالمشكلات التي رأيتها منذ بضعة أيام ، وهي أن الوحدة يمكن الوصول إليها ، لكنها تخبرني أنها تحتوي على IP 0.0.0.0.

الشيء الثاني ، على الرغم من عدم القيام بأي شيء خلال الـ 24 ساعة الماضية ، أرى قفزات مفاجئة في حمل وحدة المعالجة المركزية ، حتى في الوحدات "الصغيرة" ، التي تستخدم فقط وظيفة التبديل (على سبيل المثال ، رقم 7 في الرسم البياني المرفق).

هل هناك أي فرصة لمعرفة سبب حدوث هذه التغييرات المفاجئة في حمل وحدة المعالجة المركزية؟ لا يقول السجل شيئًا محددًا .. (حمل وحدة المعالجة المركزية من اليوم والأمس) ...

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

لا ، ليس عند إعادة التشغيل ... فقط "عشوائيًا" في مرحلة ما ... من المثير للاهتمام أنه يحدث لوحدات متعددة في وقت واحد ... ليس لدي أدنى فكرة عما حدث هناك (لم يكن المنزل في ذلك الوقت) ... خاصة الوحدات 12- 14 هي لوحات عادية حقًا بدون مهام باستثناء rssi ، التحميل ، الجهوزية والذاكرة ... كما أن الرسوم البيانية للذاكرة لا تظهر أي علامة على تغييرات مهمة ...
لا يزال التحميل على بعض الوحدات يظهر ~ 50٪ لكن واجهة الويب سريعة ..

لدي أيضًا في وحدة واحدة ساعة مدفوعة بواسطة nfx تغير موضع العقارب كل ثانية. من المثير للاهتمام أن الساعة توقفت في وقت ما ، لكن الوحدة استمرت في العمل دون مشاكل ... مثل هذه المهمة لم تعد تعمل بعد الآن ... ولكن هذا قد يكون متعلقًا بالمكوِّن الإضافي (لأنه أحد قواعد التشغيل) .. ولكن من الممكن ربما يشير إلى القضايا ...

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

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

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

كيف يتم تنفيذ الأمر ping؟ لأنني أرى بعض "المضيف غير معروف" من وقت لآخر ... هل يمكن أن تكون هذه المهلة كبيرة جدًا؟ أو أن البحث عن نظام أسماء النطاقات ping ord يضطر إلى انقضاء مهلات قصيرة؟ لم أعد أستخدم FQDN بعد الآن ، فقط عناوين IP ، لذلك من غير المرجح أن يكون DNS مشكلة ...

أنا فقط أقوم بالتحديث مع أحدث الالتزام ... بعض الوحدات سهلة التحديث وسريعة جدًا ، والبعض الآخر بطيء جدًا ...

لدي 4 نقاط وصول تعمل على نفس SSID ، هل من الممكن أيضًا أنه في بعض الأحيان يختار واحدًا أسوأ ثم يواجه مشكلات في السرعة؟

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

وهذه مكالمة حظر؟

إنه بالفعل ، لهذا السبب أريد تغييره إلى متغير غير متزامن.

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

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

هل يمكن أن يكون 0.0.0.0 هو DNS الثانوي؟

لقد أدركت ذلك مع DNS ، ولهذا السبب لا أستخدم سوى عناوين IP الآن ... لا أستخدم MQTT على الإطلاق ، فقط المكون الإضافي لوحدة التحكم fhme بالإضافة إلى استعلامات json العادية (من fhem مع المكون الإضافي HTTPMOD).

أحد الأشياء التي ربما سأجربها هو تعطيل شبكات UDP inter-ESPEasy ... لا يمكنني التخلص من الشعور بأن هذا له بعض التأثير على الوحدات ، خاصة عند تشغيل أكثر من 15 وحدة ترسل تحديثات منتظمة. ..

بعد تحديث جميع الوحدات إلى أحدث الالتزام الضخم ، عادت جميع أحمال وحدة المعالجة المركزية إلى "وضعها الطبيعي" ... هذا الصباح في حوالي الساعة 8 أعدت التشغيل Nr. 4 و 9 ، وانظر ما حدث لحمل وحدة المعالجة المركزية ، فقد بلغت ذروة جميع الوحدات تقريبًا حوالي 30 دقيقة. وعاد الى طبيعته بعد ذلك ....

مجرد فكرة سريعة: هل من الممكن أن يتم "إعادة توزيع" أحداث inter-ESPEasy UDP المستلمة إلى وحدات أخرى ، وبالتالي يمكن أن تولد حلقة وتملأ مكدس الشبكة؟

لم أنظر مطلقًا إلى رمز "الاتصالات بين ESPeasy" هذه ، لذلك لا يمكنني قول أي شيء عن ذلك.
أتوقع أن يرسل هذا البروتوكول بياناته الخاصة فقط ولا يردد صدى البقية.
يتكون هذا البروتوكول من جزأين:

1. إبداء حضورها الخاص.
2. إرسال قيم المعلمات للمكونات الإضافية عبر ما كان يُعد "مزامنة عامة".

تم استبدال هذا الأخير الآن بـ "تحكم c_013".

لكن لست متأكدًا مما إذا لم تكن هناك حلقة ممكنة. على سبيل المثال مع الأجهزة الوهمية واستيراد MQTT وما إلى ذلك.
قد يكون أيضًا سلوكًا مختلفًا بين الإصدارات القديمة والإصدارات الجديدة التي تستخدم "وحدة التحكم 13".

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

إضافة: بعد تغييره أرى حوالي 50٪ من الوحدات تعيد التشغيل (دون أن يطلب منهم ذلك) ... وبعض "HTTP: فشل الاتصال" في السجل ....

لقد لاحظت مشكلة مماثلة في حمل وحدة المعالجة المركزية. يقوم برنامج wemos بتشغيل FW مترجم ذاتيًا مع 13 ملحقًا. أنا أستخدم Rest API مع Pimatic. كما ترى لسبب ما ، يرتفع الحمل إلى 90٪ وما فوق.

للحصول على معلومات: منذ أن قمت بإيقاف تشغيل شبكات Inter-ESPEasy عن طريق ضبط المنفذ على 0 في الإعدادات المتقدمة ، يبدو (معظم) مشاكلي قد ولت! جميع الوحدات الـ 20 لديها أوقات تشغيل> 20 دقيقة. وما زالوا يقدمون تقارير منتظمة عن القيم. الويب إذا تم تشغيله وتشغيله. كما أن الرسم البياني لوحدة المعالجة المركزية لم يعد يظهر بعد الآن من هذه القفزات المفاجئة. تم تغيير وحدة واحدة فقط إلى وضع AP ، وسأرى ما إذا كانت ستتعافى ..
ربما يحتاج هذا إلى التحقيق (في المصدر) ... مع الكثير من الوحدات ، من المحتمل أن تؤدي عناصر UDP إلى زيادة التحميل على مكدس الشبكة ...
آمل أن يساعد هذا الآخرين الذين يواجهون مشكلات مماثلة ...

هنا تجربتي:
6 وحدات مع IP ثابت وشبكة Inter-ESPeasy نشطة.
أحدث البرامج الثابتة التي تم تحميلها كانت "Mega 20180505 Manual بنيت مرتين". (لكن البرامج الثابتة السابقة كانت تعمل جيدًا أيضًا).
لقد تم تشغيلهم لمدة 3 أيام تقريبًا دون أي مشكلة.

هذا أحد الأسباب التي دفعتني إلى الانتظار بضعة أيام قبل أن أقوم ببعض إصلاحات wifi / الشبكة. ما عليك سوى تركه يعمل لفترة من الوقت لمعرفة الخطأ الفعلي ومحاولة قراءة بعض المشكلات في قائمة مشكلات Arduino.
لقد لاحظت بالفعل أن عددًا من المشكلات تقترح تعطيل إدارة الطاقة لبعض تكوينات wifi. يبدو أن بعض مجموعات ESP8266 + accesspoint لا تعمل بشكل جيد مع تمكين ميزات إدارة الطاقة (والتي يتم تمكينها افتراضيًا)
لذلك هذا خيار للإضافة إلى ESPeasy.

أنا أبحث عن المزيد من الأفكار في الأيام القادمة ويوم الجمعة / السبت لدي المزيد من الوقت للتشفير.

كمرجع ، فإن نقطة الوصول الخاصة بي هي ASUS RT-AC68U مع البرامج الثابتة Merlin

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

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

كما أنها منطقية لأغراض أخرى.
المزيد من الطاقة يعني مزيدًا من الحرارة وبعضها محاط بأجهزة استشعار .... ؛)

بالإضافة إلى حمل المعالج العالي. عدت إلى FW بتاريخ 16/03 مع 2.3.0 Core وأصبح كل شيء طبيعي مرة أخرى. الأحمال الآن بحد أقصى. 25٪. كما أن وقت استجابة wemos أفضل بكثير مرة أخرى. مع كل من 08/05 و 16/03 ليس لدي قطع اتصال WiFi على الإطلاق. لا يوجد حتى الآن دليل على سبب ارتفاع الحمل. أيضًا في كلتا الحالتين لم أستخدم udp.

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

قد يكون مرتبطًا أيضًا بالقيام بمهام أطول دون وقت لبعض المكالمات إلى yield() ، وهو ما يتم أيضًا عند استدعاء delay() .
يمكنني أن أتخيل أن المكون الإضافي لشاشة LCD (وربما البعض الآخر أيضًا) يقوم ببعض المهام التي تستغرق أكثر من 10 مللي ثانية.

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

تعمل جميع الوحدات الأخرى بشكل جيد الآن ، ولكن كما قيل ، يجب تعطيل إعلان inter ESP ...

على الأقل شبكة WiFi مستقرة مثل هذا ، ولا توجد مشكلات أخرى تتعلق بالاتصال حتى الآن ... (تشغيل أكثر من 20 وحدة حتى الآن)

هل قمت بتمكين التسجيل على المنفذ التسلسلي؟
هل يمكنك ضبط ذلك على "لا شيء"؟

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

انا ذاهب الى تغييره إلى "لا شيء" على حدة، وسوف نرى ما اذا كان هذا يحدث فرقا ..

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

طيه الفرق بين النواة 2.3.0 و 2.4.1 10 مايو لقد قمت بتغيير FW من 2.4 إلى 2.3. الإعدادات والقواعد لكليهما هي نفسها تمامًا.

jopiekr : ما هو البرنامج الذي تستخدمه لطباعة حمل وحدة المعالجة المركزية؟

@ gii1967g هو pimatic. قم بتشغيله على OrangePi One لأكثر من عام دون أي مشاكل. كنسخة احتياطية أيضًا على Raspberry Pi. pimatic.org

غيرت جميع السجلات التسلسلية إلى لا شيء الآن ... سأرى ما سيحدث ...

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

لقد لاحظت فوق -77 ديسيبل أنها يمكن أن تصبح غير مستجيبة. أيضًا عندما لا يتم تشغيلها بالبطارية ، تحقق من تجديد وقت الإيجار لجهاز التوجيه الخاص بك. لقد وضعت قاعدة لإعادة تشغيلهم بعد 12000 دقيقة.

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

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

أنت تعرف أيضًا أقوى RSSI ، لذا اتصل بالأقوى أولاً وحاول دائمًا إعادة استخدام آخر مرة تم استخدامها أولاً
وعندما يكون الاتصال غير مستقر ، حاول تعطيل ميزة توفير الطاقة التي يتم تمكينها افتراضيًا في 2.4.x core.
قد تتسبب ميزة توفير الطاقة هذه في إعادة الاتصال بشبكة wifi أو توقفها عند التصفح عبر صفحات الويب أو حتى الرفض عند الاتصال.

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

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

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

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

@ TD-er حول معالجة WiFi: أتفق تمامًا مع وظيفة إدارة الطاقة. يجب أن يكون المرء قادرًا على إيقاف تشغيله ، حيث يمكن أن يتسبب في حدوث مشكلات غريبة حقًا وأجهزة بطيئة ...

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

أوافق على إجراء مسح ضوئي داخل الكود الخاص بك ثم تحديد الرمز الذي يجب أخذه بناءً على RSSI و BSSID المعروف ...

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

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

عند إعادة التشغيل وإذا فشلت المحاولة الأولى لإعادة الاتصال ، فسيتم إجراء فحص واختيار أقوى تطابق لـ SSID المحدد.

سأغير ذلك إلى تخزين BSSID لنقطة الوصول المفضلة في الإعدادات ، لجعل BSSID هو المفضل دائمًا.
عمليات إعادة الاتصال سريعة حقًا إذا كانت القناة معروفة أيضًا. (200 مللي ثانية أقل من الممكن ، اعتمادًا على نقطة الوصول المستخدمة)
كما يستغرق إعداد IP الثابت حوالي 20-25 ميللي ثانية ، مقارنة بـ DHCP الذي يستغرق 2.5 - 10 ثوانٍ.
سيكون ذلك مثاليًا للأجهزة التي تعمل بالبطاريات.

لذلك هناك مجال للتحسين :)

يبدو واعدا جدا. حتى الآن لديّ شهرين من عمر البطارية مع بطاريات 2AA تصل إلى 3.3 فولت ومستشعر DHT يرسل كل 900 ثانية. هذا موجود على لوحة RobotDyn ESP Pro مع منظم الجهد الذي تمت إزالته.

@ TD - إيه فقط حاولت البناء من أمس. لا يمكنني رؤية أي اختلاف في أوقات الاتصال إذا كنت أستخدم IP ثابتًا أو dhcp. يستغرق كلا الوصلين حوالي 3 ثوانٍ بعد إعادة التعيين.

ثم لديك خادم DHCP سريع.
يستغرق My Fritzbox حوالي 2.5 ثانية لـ DHCP ، بعد 2.5 ثانية من الاتصال بشبكة wifi.
لذلك يستغرق إعداد اتصال MQTT + NTP حوالي 6 - 6.5 ثانية من التمهيد.

صندوق فريتز 7490.

تحديث سريع: بعد تعطيل InterESP UDP (وإزالة C13 من وحدة 1M) وضبط السجل التسلسلي على "non" (يؤدي أيضًا إلى تعطيل المنفذ التسلسلي) ، تعمل جميع وحداتي تقريبًا بشكل ثابت خلال آخر 30 ساعة ... مزيج بين D1 Mini و D1 pro و Sonoff Basic و Dual و 4ch ... 20+ وحدة ... تعمل على الالتزام من ميجا 20180511 ، مجمعة ذاتيًا باستخدام Arduino IDE ...

لدي 7581 كمودم و 3 * 1750E كنقاط وصول.

راجع للشغل: أنا أعمل على Mikrotik AP's (وواحد من USR قديم حقًا). الذهاب لتحديث الوحدات الآن بآخر التزام من الليلة ...

تتعامل أحدث الالتزامات حاليًا فقط مع الكود المرتبط بـ JSON (عارض السجل + قيم مستشعر التحديث).
ليس بعد مع رمز wifi.

بالتأكيد ، ولكن يبدو أن wifi "مستقر بدرجة كافية" مع أحدث عمليات الالتزام ، لذلك أريد أن أكون على اطلاع دائم بوحداتي ؛)

آسف لإحضار هذا الأمر مرة أخرى ، لكنني ما زلت أواجه مشكلة أن ESP يعتقد أنه يحتوي على IP يبلغ 0.0.0.0 ويتوقف عن التحدث إلى الخادم ، قليلاً على مستوى الشبكة والويب ، كل شيء على ما يرام! انظر لقطة الشاشة المرفقة ، جربتها باستخدام تركيبة مختلفة من ESPEasy و esp8266 ...
هل شخص ما eslse expierience هذا؟

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

لا ، متصل عبر الشبكة مباشرة. يعمل ping و http بدون مشاكل ، بسرعة (انظر عنوان IP الخاص بالعميل هو 10.0.0.10 وهو جهاز الكمبيوتر المحمول الخاص بي ، والشبكة الداخلية 10.0.0.0/16) ... نعم ، غريب جدًا على الرغم من ذلك ..
cuold يكون مرتبطًا بـ DHCP أو نحو ذلك .. بعد إعادة التشغيل كل شيء على ما يرام مرة أخرى ..

هل يمكن أن يكون مرتبطًا بحقيقة أنني قمت بتمكين وحدة تحكم واحدة فقط (FHEM) ولم يتم تمكين وحدة تحكم MQTT؟ رأيت الكثير من التعليمات البرمجية mqtt في المصادر ، خارج المكون الإضافي لوحدة التحكم ... مجرد تخمين ... لكنني أعتقد أنه ليس مرتبطًا حقًا ...

ربما انتهت صلاحية dhcp ولم يتم تجديدها؟

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

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

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

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

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

هل من الممكن ألا يتم إعادة تشغيل العقدة المعلقة الخاصة بك بعد الوميض؟ (اضغط على إعادة تعيين أو دورة الطاقة)

من الممكن ألا يكون هناك إعادة تشغيل بعد الوميض. لكنها كانت ومضة عبر شبكة الاتصالات العالمية ، وليست مسلسل.

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

حسنًا ، بعد أن عانيت من العديد من مشكلات الاستقرار ومشكلات wifi الغريبة مع أحدث إصدارات البرامج الثابتة ، كان علي العودة إلى الإصدارات السابقة في النهاية. على سبيل المثال ، حتى حدث انقطاع التيار الكهربائي مؤخرًا ، كانت عقدة ESP12E قديمة مع mega-20180311dev تعمل لمدة 70 يومًا ، وترسل بيانات درجة الحرارة إلى ThingSpeak.
في عقدة أخرى بعد الترقية إلى mega-20180522dev ، كنت أعاني من إعادة تشغيل بسبب استثناء كل 24 ساعة تقريبًا على الرغم من إعادة التعيين إلى الإعدادات الافتراضية ، فقط أعمل بدون تكوين أي جهاز ، بدون تكوين NTP ، بدون تحكم ... بعد الرجوع إلى الإصدار mega-20180324 قبل يومين ونصف ، احتفظ بالتكوين ، وقم فقط بتمكين NTP مرة أخرى وحتى الآن يتم تشغيله. على الرغم من وجود بعض الأخطاء والميزات المفقودة في هذه الإصدارات القديمة ، إلا أنها الخيار الأفضل حاليًا بالنسبة لي.

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

أعلم ولكني أفضل عقدة مستقرة بدون إعادة تشغيل مجدولة. لا أعرف ما إذا كان الاستقرار قد انخفض بشكل كبير بسبب التحول إلى Core 2.4.1 (ربما لم ينضج بما فيه الكفاية بعد) أو إذا كان مرتبطًا بإعادة تصميم ESP Easy ولكنه حدث على الرغم من الجهد الأقصى لجميع مساهمي ESP Easy. إنني أقدر حقًا العمل الشاق لكم جميعًا ولكن لا يمكنني حاليًا استخدام أحدث إصدارات ESP Easy بعد الآن.

أعتقد أنه مرتبط أيضًا بالمكوِّن الإضافي المستخدم أو ربما مجموعة من المكونات الإضافية.

عملت الأسبوع الماضي على النظر في تأثيرات التوقيت وأنا متأكد من أنه سيكون له تأثير كبير على المهام الحرجة للوقت.

لقد ألقيت نظرة على بعض العقد الخاصة بي ، وكلها تعمل بالبنية الرسمية:

اسم الملف الثنائي ESP_Easy_mega-20180513_normal_ESP8266_4096.bin

الوحدة 3

• الجهوزية 16 يوم 18 ساعة 26 دقيقة
• متصل 5d23h07m
• سبب قطع الاتصال الأخير (201) لم يتم العثور على AP
• عدد يعيد الاتصال 2

الوحدة 5

• الجهوزية 11 يوم 5 ساعات 22 دقيقة
• متصل 5d22h57m
• سبب قطع الاتصال الأخير (201) لم يتم العثور على AP
• عدد يعيد الاتصال 4

وحدة 6

• الجهوزية 11 يوم 5 ساعات 23 دقيقة
• متصل 45 م 1 ثانية
• سبب قطع الاتصال الأخير (201) لم يتم العثور على AP
• الرقم يعيد الاتصال 58

اسم الملف الثنائي ESP_Easy_mega-20180619_test_ESP8266_4096.bin

الوحدة 7

• الجهوزية 13 يوم 20 ساعة 51 دقيقة
• متصل 5d23h05m
• سبب قطع الاتصال الأخير (202) فشل المصادقة
• عدد يعيد الاتصال 2

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

الوحدة 6 متصلة بنفس الوحدة 3 و 7 ، ولكن لديها الكثير من عمليات إعادة الاتصال.
تقع هذه الوحدات الثلاث بجوار بعضها البعض ، على بعد متر واحد من بعضها البعض لمقارنة مستشعرات ثاني أكسيد الكربون المختلفة (MH-Z19 A و B و SenseAir S8) وجميعها مدعومة بنفس مصدر الطاقة (شاحن USB بثلاثة منافذ من ايكيا).

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

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

أستخدم دائمًا الإصدارات الرسمية لأنني غير قادر على إعداد بيئة التطوير لهذه الأجهزة والحفاظ عليها.
كان الإصدار mega-20180522dev المذكور أعلاه ، كما وصفته أعلاه ، تكوينًا فارغًا تمامًا ، لذا لم يتم استخدام أي مكونات إضافية على الإطلاق ، ولا توجد قواعد ، بل لقد قمت بحذف وحدة التحكم الافتراضية Nr1 في النهاية. لا شيء يمكن أن يوقف العقدة من إعادة التشغيل بسبب استثناء على فترات تتراوح بين 24-40 ساعة.

لا أعرف ما إذا كانت مشكلة wifi - لا يبدو الأمر كذلك ، لقد تمكنت من تعيين عناوين IP ثابتة لشبكة wifi ، ولكن لا يزال من السهل إحضارها بواسطة dhcp وتعيينها بشكل مختلف.

1104 : WD   : Uptime 0 ConnectFailures 0 FreeMem 21800
1105 : S
W   : State 1.00
1106 : EVENT: x#w=1.00

scandone

state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 2
c
nt 

connected with BJ3, channel 12
dhcp client start...
4350 : WIFI : Connected! AP: BJ3 (E8:DE:27:4F:66:86) Ch: 12 Duration: 3760 ms
4351 : EVENT: WiFi#ChangedAccesspoint
4355 : IP   : Static IP : 192.168.2.184 GW: 192.168.2.1 SN: 192.168.2.0 DNS: 8.8.8.8
4360 : WIFI : Static IP: 0.0.0.0 (ESP5-5) GW: 0.0.0.0 SN: 0.0.0.0   duration: 11 ms
4367 : EVENT: WiFi#Connected
4374 : Webserver: start
4374 : WIFI  : Arduino wifi status: WL_DISCONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_SERVICES_INITIALIZED
ip:192.168.2.123,mask:255.255.255.0,gw:192.168.2.1
4400 : WIFI : Static IP: 192.168.2.123 (ESP5-5) GW: 192.168.2.1 SN: 255.255.255.0   duration: 50 ms
4401 : EVENT: WiFi#Connected
4406 : WIFI  : Arduino wifi status: WL_CONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_SERVICES_INITIALIZED
4500 : MQTT : Intentional reconnect
4501 : LoadFromFile: config.dat index: 28672 datasize: 724

@ uzi18 هل قمت بتعيين جميع الحقول

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

@ TD-er نعم ، تم ملء جميع البيانات - كما ترى في السجل.
لقد تومضت وحدة جديدة ، مع
INFO: المكونات الإضافية: 71 [عادي] [اختبار] (ESP82xx Core 2_4_1، NONOS SDK 2.2.1 (cfd48f3)، LWIP: 2.0.3)
وهي تعمل من هذا القبيل.
تم أخذ الوحدة النمطية فقط من الحقيبة الأصلية وميضها ، ولم يكن espeasy موجودًا من قبل.

@ TD-er: فكرتان حول ذلك:

1. يعمل نظام التدفئة الخاص بي بدون ESPEasy إلى مذيع MQTT بشكل لا تشوبه شائبة باستخدام أحدث عميل pubsub. لا إعادة الاتصال وهلم جرا. ربما تتداخل مراقبة التوصيلية ESPEasy مع ما قامت به المكتبة الأساسية بالفعل. هل يجب أن يكون لدينا طريقة لتعطيل كل هذه الأشياء الإضافية ping-ren connect-wifistate؟ فقط للاختبار؟
2. هل أنت على علم بإيقاف تشغيل wifi التلقائي؟ https://blog.creations.de/؟p=149

سيكون لطيفًا إذا تمكن شخص ما لديه شبكة wifi غير مستقرة إلى حد ما من اختبار هذا العلاقات العامة: https://github.com/letscontrolit/ESPEasy/pull/1562

@ TD-er عثرت للتو على https://github.com/esp8266/Arduino/pull/4718
يتعامل مع مشاكل إعادة الاتصال lwip. تم إصلاحه في هذه الأثناء. ربما تريد تخطي ذلك ...

أستخدم دائمًا أحدث إصدار من GIT من esp8266 .. ولهذا السبب ربما لا أرى مشكلة 0.0.0.0 بعد الآن ...

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

لتسهيل ذلك في المستقبل ، قمت بتعديل القواعد:

on S1#Switch do
timerSet,1,5 
if [R1#Relay]=1
gpio,12,0
else
gpio,12,1
endif
endon

on S2#Switch do
if [R2#Relay]=1
gpio,13,0
else
gpio,13,1
endif
endon

On Rules#Timer=1 do
if [S1#Switch]=1.00
 reboot
endif
endon

الآن ستكون الحياة أبسط :))

أقوم بإعادة التشغيل كل 24 ساعة. يؤدي هذا إلى إحياء عقدة واحدة ببرنامج ثابت من 4 أسابيع مضت مرتين في الأسبوع.
ربما يجب أن تكون هذه ميزة دائمة ....

لا تزال هذه القضية؟ إذا كان الأمر كذلك ، يرجى إعادة الفتح.

أطول موضوع لدينا في قائمة القضايا ....