يبدو أنه مرتبط بالتغيير في المسلسل الذي أجريته مؤخرًا.

ما دبابيس gpio التي تستخدمها؟

ربما ، دعنا نرى ، أعتقد أنك وجدت نقطة Gijs :-)

esp01 = Gpio0 Gpio2 (لم تظهر أي مشاكل بعد)
esp02 = Gpio14 Gpio12
esp08 = Gpio14 Gpio12
esp18 = Gpio14 Gpio12

نفذ

لدي عقدتان هنا يمكنني أيضًا اختبارهما لاحقًا بعد ظهر هذا اليوم

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

ما هي مدة "بعد فترة"؟
لقد قمت للتو بإعداد عقدة باستخدام أحد هذه المستشعرات وأيضًا تم توصيل BMP280.
تستخدم GPIO-14 & -12 لمستشعر ثاني أكسيد الكربون.

ساعتان ، بالأمس كان كل شيء يعمل ، هذا الصباح كان لدي 3 من أصل 4 بنفس الحالة.

وقاموا جميعًا بالتمهيد في نفس الوقت تقريبًا ، قبل أن يتوقفوا جميعًا عن العمل؟

نعم ، تم إعادة تشغيل / تحديث كل شيء في غضون ساعة على ما أعتقد ، تم تحديثها مساء أمس. وأثناء الليل توقفوا عن العمل

كنت على وشك تحديث العقد ولكن لحسن الحظ لاحظت ذلك. @ TD-er الذي سيكون أحدث إصدار قبل التغييرات على Serial التي تخمن أنها قد تكون الجاني؟ أم أنه سيكون أكثر فائدة إذا قمت بعمل وميض أحدث إصدار لمعرفة ما إذا كنت سأواجه نفس المشكلة؟

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

لقد قمت بإرجاع إصدار 3 "مشكلة" esp's إلى 20181231 بالأمس ، ويمكنني التأكيد على أنهم ما زالوا يرسلون البيانات دون أي تغييرات في الأجهزة ، والآن لمدة 24 ساعة ، لذلك لا يزال هؤلاء الثلاثة يستخدمون gpio12 و gpio14 في حالتي

أي حظ في إعادة إنشائه Gijs؟

كلا ، لا تزال عقدي ترسل القيم وهي تعمل على الإنشاء اعتبارًا من 16 كانون الثاني (يناير). (كور 2.5.0)

لقد استخدمت ESP_Easy_mega-20190116_normal_core_241_ESP8266_4096.bin على تلك العقد ، التي تحتوي على 2.4.1 الأساسية على ما أعتقد؟

pwassink هذا صحيح.
يمكنك أيضًا رؤية البنية الأساسية في صفحة sysinfo.

لقد قمت بتثبيت هذا الإصدار ESP_Easy_mega-20190116_normal_core_241_ESP8266_4096.bin مرة أخرى إلى esp02 هنا ، دعنا نرى ما إذا كان سيحدث مرة أخرى

همم،
ربما يكون ليوم الأسبوع أو موقع القمر تأثير معين ،
لم أر الخلل يتكرر هنا خلال الأيام الماضية.

يبدو أنه يعمل بشكل جيد هنا أيضًا.
لقد كان البدر تقريبًا عندما أبلغت عنه ، لذلك أعتقد أنه كان يجب أن يكون ؛)

تحديث،

تركت esp02 قيد التشغيل مع إصدار ESP_Easy_mega-20190116_normal_core_241_ESP8266_4096.bin الذي لا يزال يعمل كما ينبغي.

بالأمس قمت بتحديث بقية العقد الخاصة بي إلى ESP_Easy_mega-20190121_normal_core_241_ESP8266_4096.bin

وذهب esp-18 مرة أخرى في الساعة 06:55 بالتوقيت المحلي ، وكل شيء يعمل كما ينبغي ، باستثناء مستشعر MHZ19 Co2 ، في علامة تبويب الأجهزة ، يعرض "آخر قيمة جيدة معروفة" من حوالي الساعة 07:00 ومرة ​​أخرى بنفس الإدخالات في ملف السجل:
MHZ19: خطأ ، انتهت المهلة أثناء محاولة القراءة
MHZ19: استجابة غير معروفة: 0 0 0 0 0 0 0 0 0

يستخدم Esp-18 Gpio 14/12
إنه Nodemcu مع Ch340 الإصدار 2 من 3 من Ali
إعادة التشغيل عن بعد عبر وحدة تحكم الويب لم تحل المشكلة
مرة أخرى يتم عرض تلك الإدخالات المذكورة أعلاه عدة مرات
بعد powercycle
78640: MHZ19: خطأ ، انتهت المهلة أثناء محاولة القراءة
78641: MHZ19: قراءة خطأ: المجموع الاختباري = 202/0 بايت قراءة => 255/168/12/161/226/255 / 0/0/0 /
78643: MHZ19: تم إزاحة 1 بايت لمحاولة إصلاح محاذاة المخزن المؤقت
بعد مزيد من الوقت:
255652: MHZ19: قيمة جزء في المليون: 1584 قيم درجة الحرارة / S / U: 25/0 / 0.00
255656: الحدث: Rik-CO2 # PPM = 1584.00
255656: الحدث: Rik-CO2 # PPM = 1584.00 زمن المعالجة: 1 مللي ثانية
255659: الحدث: Rik-CO2 # درجة الحرارة = 25.00
255659: الحدث: Rik-CO2 # درجة الحرارة = 25.00 زمن المعالجة: 1 مللي ثانية
255662: الحدث: Rik-CO2 # U = 0.00
255662: الحدث: Rik-CO2 # U = 0.00 وقت المعالجة: 1 مللي ثانية

يبدو أنه يعمل مرة أخرى الآن ، لكنه يحتاج إلى powercycle حوالي دقيقتين بدون طاقة

هل يحتاج إلى فعل شيء في تلك اللحظة؟ هل يمكن أن يكون شيئًا قد يؤدي إلى حدوث فوضى في شبكة wifi على المرساب الكهروستاتيكي؟

لاشىء على الاطلاق،

لا توجد عمليات إعادة تعيين مجدولة أو عمليات إعادة تمهيد أو نسخ احتياطي أو إعادة تعيين wfi أو عمليات تنظيف dhcp أو أي سبب خارجي في ذلك الوقت

وتستمر شبكة wifi في العمل بشكل جيد ، إنها مجرد قراءة mhz19 التي تتوقف ، ولا تزال جميع أجهزة الاستشعار الأخرى (القائمة على i2c) على نفس esp تعمل

حدث هذا الصباح في الساعة 03:00 مرة أخرى مع تشغيل Esp-18 للإصدار 0121 Mega ، نفس الأخطاء في ملف سجل esp كما كان من قبل ، تعمل المستشعرات الأخرى بشكل جيد

وفي الساعة 19:05 ، تعطل esp02 الذي يعمل مع ESP_Easy_mega20190116_normal_core_241_ESP8266_4096.bin أيضًا ، كما هو الحال أعلاه ، لا توجد بيانات بعد الآن ونفس الإدخالات في التسجيل.

مرة أخرى 2 hickups اليوم ، حدث كل من esp02 و esp18 بشكل خاطئ مرة أخرى نفس الأخطاء في السجل
إصدارات البرنامج 2 متضمنة ، 0116 و 0121 كلاهما 2.4.1 كور و 4 ميجا بايت الإصدار
أجهزة esp02 عبارة عن nodemcu-d1-mini / esp18 عبارة عن nodemcu-v2 يستخدم كلاهما gpio12 / gpio14

هل يمكنك تجربة هذا البناء على إحدى العقد الخاصة بك؟

ESP_Easy_mega-20181109_normal_ESP8266_4096.bin

إنه يعمل على إحدى العقد الخاصة بي باستخدام MH-Z19 ولديه الآن وقت تشغيل يبلغ 54 يومًا و 23 ساعة و 21 دقيقة
هذا منذ انقطاع التيار الكهربائي ...
يعمل هذا بشكل جيد مع التحديثات المنتظمة لقيمة ثاني أكسيد الكربون.

انا سوف،

لكني ذكرت من قبل ذلك حتى الإصدار الضخم 20181231 core 2.4.1 عادي 4 ميجا بايت ، لم يتم رؤية أي من مشكلات الاستقرار المبلغ عنها ، فلماذا هذا الإصدار المحدد؟

سوف أقوم بتنزيل هذا الإصدار المحدد عند تثبيته على عقدتي قياس eesp02 و esp18 ، ولكن ظهرت المشكلات في النطاق الضخم 2019 * وليس سابقًا في رأيي المتواضع Gijs ..

حسنًا ، لا فائدة منه حقًا.

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

مع ذلك،
يتم تشغيل Esp02 و esp18 على ESP_Easy_mega-20181109_normal_ESP8266_4096.bin الآن
يتم تشغيل Esp01 و Esp08 على ESp-Easy_mega_20190121_normal_core_241_ESP8266_4096.bin

وسوف نرى

ملاحظة ، لقد أدركت للتو أن الإصدار 1109 يحتوي على رقم الإصدار 20102 بحيث يكون هذا طريقًا للوراء ومختلفًا؟

جيجس ،

ربما وجدت دليلًا آخر حول هذه المسألة.

منذ دقيقتين ، توقف Esp08 A nodemcu ch340V2 4Mb الذي يعمل ESp-Easy_mega_20190121_normal_core_241_ESP8266_4096.bin عن إرسال co2data aslo.

مقتطف السجل
370508579: UDP: 60: 01: 94: 0F: AF: 9D، 192.168.3.46،17
370508785: UDP: 24: 0A: C4: 82: F2: B8،192.168.3.51،21
370509501: UDP: 60: 01: 94: 0C: 2E: FD، 192.168.3.48،19
370514624: UDP: 5C: CF: 7F: 82: FD: 47192.168.3.31،2
370515674: MHZ19: قراءة خطأ: المجموع الاختباري = 120/248 بايت قراءة => 255/134/5/183/71/128/15/112/248 /
370515677: MHZ19: تم إزاحة 1 بايت لمحاولة إصلاح محاذاة المخزن المؤقت
370517702: الحدث: الساعة # الوقت = الأربعاء ، 12:19
370517755: الحدث: الساعة # الوقت = الأربعاء ، 12:19 وقت المعالجة: 53 مللي ثانية
370520257: UDP: 60: 01: 94: 0B: 94: 5C، 192.168.3.30،1
370520460: UDP: 60: 01: 94: 02: 0E: E8،192.168.3.36،7
370523940: UDP: 18: FE: 34: E2: 18: 84،192.168.3.35،6
370529880: UDP: BC: DD: C2: EA: 3D: BC، 192.168.3.54،24

هذه هي المرة الأولى التي أرى فيها هذا الخطأ ، ربما ..

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

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

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

لكن وجدت هذا بعد ذلك:
في حوالي 1800 بالتوقيت المحلي ، دخل إلى الحالة المحظورة ، وإعادة التعيين ، وإعادة التشغيل من خلال powercycle وحدة التحكم ، لم ينجح شيء هذه المرة ، احتاج الجهاز إلى إعادة وميض بإصدار 20181231 4 ميجا بايت ثم عاد إلى الحياة مرة أخرى. يستخدم Esp08 تركيبة Gpio12 / 14 وهو نموذج nodemcu v2 ch340 أيضًا

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

قد يكون،

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

أو لا يستخدمه الأشخاص الذين يشغلون أحدث الإصدارات

لدي 2 MH-Z19b ، كلاهما يعمل على اختبار 20190116 بدون مشاكل

حسنًا ، هل ترغب في معرفة أي إصدار أساسي من بنية الاختبار وأي إصدار Gpio تستخدمه بالضبط؟

أرى 1 يقوم بتشغيل ESP_Easy_mega-20190116_test_core_250_beta_ESP8266_4096.bin ، والآخر ESP_Easy_mega-20190121_test_core_250_beta_ESP8266_4096.bin. على كلا المستشعرين المتصلين بـ GPIO 13 و 12

هذا هو جوهر آخر و GPIO آخر أنت تستخدمه في 13/12 بدلاً من GPIO 14/12 الذي أستخدمه هنا

لقد قمت اليوم بتحديث 4 من 4 إلى إصدار ESP_Easy_mega-20190202_normal_core_241_ESP8266_4096.bin

دعنا نرى

الآن بعد أن فكرت في الأمر ، قد يكون هناك تغيير آخر في مكتبة SWserial المستخدمة منذ بداية هذا العام.
اعتدنا أن يكون لدينا نسختنا الخاصة من مكتبة SWserial ، والتي قمت بتصحيحها لاستخدام ذاكرة iRAM أقل.
لكننا الآن نستخدم الإصدار المضمن في المكتبة الأساسية وقد يكون هذا الإصدار أحدث من الإصدار 2.5.0 الأساسي.
قد يكون هناك أيضًا بعض التغيير في استخدام المقاطعات على التوصيلات منخفضة السرعة. (9600 باود وأقل)
يجب أن أنظر إلى ذلك أيضًا.

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

في غضون 3 ساعات بعد التحديث إلى ESP_Easy_mega-20190202_normal_core_241_ESP8266_4096.bin ، تم قفل esp18 مرة أخرى ، ولم تنجح إعادة تشغيل وحدة التحكم على الويب ، وكان من الضروري إيقاف تشغيل الطاقة مرة أخرى.
الآخر لا يزال يعمل ، سيضيف هنا إذا تم تجميد MHZ19 أيضًا

نعم ، توقف الجهاز الآخر esp18 عن إرسال بيانات CO2 المعقولة في الساعة 19:05 هذا المساء ، لذا فإن الخطأ مستمر في الأمس 202 ميجا الأساسية 2.4.1 على الأقل.
لقد عاد هذا الشخص ولم يتم ترقيته إلى إصدار 20181231 الآن أيضًا.

في حوالي منتصف الليل ، تجمد esp ، esp02 مع قراءات Co2 ، تم تخفيض التصنيف أيضًا إلى 20181231 الآن

الوحيد الذي لا يزال يعمل على ESP_Easy_mega-20190202_normal_core_241_ESP8266_4096.bin هو الذي يستخدم Gpio-0 / Gpio-2 ، الثلاثة الآخرون الذين تجمدوا يستخدمون Gpio14 / gpio12.
لا أعتقد أن هذه مصادفة بعد الآن ،

سوف أقوم بتغيير أسلاك esp02 إلى Gpio-0 / Gpio-2 وترقيتها إلى الإصدار 0202 الأساسي 2.4.1 مرة أخرى وقد نرى ما إذا كان هذا سيبقى على قيد الحياة بعد تغيير gpio هذا.
منجز

لقد أضفت للتو التزامًا بإجراء بعض التحسينات على القراءة.
راجع https://github.com/TD-er/ESPEasy/commit/3d507bdbb9dc6dd4aee2ce0c7ce6c809ea7dfb7c

هل يمكنك إنشاء نسخة تجريبية لها ، أم تريد مني إنشاء واحدة؟

إذا كان بإمكانك أن تزودني بصندوق ، فسأكون سعيدًا بوضعه على كلاهما لا يزال قيد التشغيل gpio12 / 14 esp's
ومن ثم يتم التأكد من أن الملف هو نفسه ، ولا توجد تأثيرات محلية إلخ ..

حسنًا ، استغرق الأمر بعض الوقت ، ولكن ها هو الإصدار التجريبي

فهمتك،

يعمل كل من Esp08 و esp18 على هذا الإصدار التجريبي مع نواة 2.4.1 الآن ، وكلاهما يستخدم gpio12 / 14

دعنا نرى !

يجب أن ترى أيضًا بعض المؤشرات التي توضح عدد الأسطر التي تمت معالجتها وعدد مرات فشل CRC

نعم ، لديّهم في وحدة التحكم أيضًا الآن!

سيترك هذين الرقمين ونرى في فترة زمنية معينة ما إذا كانت هذه العدادات تزيد.
حافظ على النشر ..

كلا المستشعرين المستخدمان في عقد الاختبار هما نسختان من النوع B ، لذا نجح الاكتشاف أيضًا

المجموع الاختباري (اجتياز / فشل): | 11/0
- 08 -
تم الكشف: | MH-Z19B

المجموع الاختباري (اجتياز / فشل): | 8/0
- 18 -
تم الكشف: | MH-Z19B

هل لديك أيضًا مزيج من MH-Z19 A / B أو إصدارات B الأحدث فقط؟
لا ينبغي أن يهم ، مجرد فضول.

هل لديك أيضًا مزيج من MH-Z19 A / B أو إصدارات B الأحدث فقط؟
لا ينبغي أن يهم ، مجرد فضول.

إصدارات B ، أضفت هذه المعلومات للتو ، نجح الاكتشاف أيضًا :-)

تحديث صغير ، لا تزال جميعها تعمل بشكل جيد ، وتلك التي تحتوي على نسختك الخاصة esp8 و 18 تظهر عدادات متزايدة ولكنها لا تزال خالية من الأخطاء أو أخطاء المجموع الاختباري ، والقيم الحالية هي:

Esp08: المجموع الاختباري (نجاح / فشل): | 1795/0
Esp18: المجموع الاختباري (نجاح / فشل): | 724/0

والآخر الذي فشل esp02 بشكل متسق تمامًا لا يزال يعمل الآن مع Gpio's المتغيرة
وبالتالي فإن di-mini لديها الآن mhz19 على Gpio-0 / Gpio-2 و Mega 20190202 الإصدار الأساسي 2.4.1

حذف Bummer المنشور هنا عن طريق الخطأ ، حاول إعادة إنشائه من ذاكرتي:

بالأمس ظهر ثلاثة من أجهزة الاستشعار الخاصة بي 02 و 08 و 18 باللون الأحمر على Domoticz ، ولا توجد بيانات لمستشعر Co2.
اثنان منهم يحتويان على الإصدار الخاص core 2.4.1 ، و gpio 12/14. لم تحل إعادة تشغيل وحدة تحكم الويب المشكلة ، وتم إنتاجها فقط: MHZ19: استجابة غير معروفة: 0 0 0 0 0 0 0 0 0 ولكن قياسات esp18 co2 اكتسبت الحياة مرة أخرى بعد ساعة تقريبًا ، في 0:56 بدأت في إرسال القيم المناسبة مرة أخرى.

تلقى Esp08 أيضًا إعادة تشغيل ، و esp02 أيضًا (هذا واحد لديه gpio0 / 2 الآن مثل esp01) لم يتعافى كلاهما ، وهذا الصباح حصل كلاهما على دقيقتين من انقطاع التيار الكهربائي ، بعد ذلك عاد كلاهما إلى الحياة بشكل جيد.

لقد غيرت الآن إصدار البرنامج على esp02 إلى ESP_Easy_mega-20190202-58-PR_2235_normal_core_250_beta_ESP8266_4 حتى نتمكن من اختبار هذا الإصدار الأساسي أيضًا ، لم يُحدث gpio chnage فرقًا عند تشغيل الإصدار القديم (2.4.1 الحالي) أصبح واضحًا
أظهر esp02 فشلًا في المجموع الاختباري واحدًا اليوم: المجموع الاختباري (اجتياز / فشل): | 79/1

لقد قمت أيضًا بتنشيط syslog لـ esp08 فقط في البداية ، مع الإعدادات أيضًا أدناه ، إذا كنت تريد إعدادًا محددًا ، فيرجى السؤال.

ربما يمكنك أيضًا تفصيل التكوينات الخاصة بك في المنشور (يمكن أيضًا أن تكون المشاركة التالية ، لا داعي لتعديل هذه التهيئة) توضح ما يلي:

• رقم الوحدة الداخلية الخاص بك (للإشارة الخاصة بك مثل "02 ، 08 ، 18)
• بناء الجري
• عدد قليل من النجاح / الفشل (إن وجد)
• نوع الفشل / القضية

المعلومات المفصلة (بالنسبة لي) أسهل في المتابعة مقارنة بالنص الوصفي.
أنا أيضا أرد من هاتفي في بعض الأحيان.

esp08 / 18 ESP_Easy_mega-20190202-58-PR_2235_normal_ESP8266_4096 core 2.4.1 gpio12 / 14
esp01 / 02 ESP_Easy_mega-20190202-58-PR_2235_normal_core_250_beta_ESP8266_4096 gpio 0/2

- التجميد يعني القلق جيدًا باستثناء قراءات ثاني أكسيد الكربون

22:57 تم تجميد esp08 مرة أخرى ، المجموع الاختباري للعدادات (اجتياز / فشل): | 1077/2 ضع سجل النظام جانبًا عند العثور عليه.
تم تجميد esp18 05:05 مرة أخرى ، المجموع الاختباري للعدادات (اجتياز / فشل): | 1076/2
06:25 تم تجميد esp08 مرة أخرى ، بدون عدادات ، تم تحطيم esp بالكامل هذه المرة ، حصلت على سجل النظام
12:57 تم تجميد esp18 مرة أخرى. عدادات المجموع الاختباري (اجتياز / فشل): | 116/2
20:43 تم تجميد esp18 مرة أخرى ، المجموع الاختباري للعدادات (اجتياز / فشل): | 316/2 حاول الأمر مهزرسيت
لا توجد تغييرات على الإطلاق ، يرسل المستشعر استجابة غير معروفة mhz19 0 0 0 0 0 0 0 0
رسالة مرارًا وتكرارًا ، حاولت عدة محاولات بلا حل ، دورت الطاقة العقدة.

جيجس ،

لقد أجريت بعض التحليلات على آخر سجل نظام لـ esp08 ، خلال ساعات تشغيله ، رأيت 78 مرة:
2019-02-08T05: 27: 07.581181 + 01: 00 hub08 EspEasy - - - EspEasy: MHZ19: استجابة غير معروفة: ff 0 0 0 0 0 0 0 0

البحث الآلي باستخدام #cat messages-Crash-esp08-0625 | grep MHZ19 | استجابة grep | grep 'ff 0 0 0 0 0 0 0' | مرحاض -l

وبعد تغيير خط cmdline هذا إلى المتغير الثاني غير المعروف الاستجابة ، تم حساب لينكس 408 أضعاف هذا الخط:
2019-02-08T10: 44: 06.855432 + 01: 00 hub08 EspEasy - - - EspEasy: MHZ19: استجابة غير معروفة: 0 0 0 0 0 0 0 0 0

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

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

تحرير: هذا الأمر هو mhzreset

يجب أن يكون هناك بعض التغيير بعد 20181231 الضخم 2.4.1. إصدار 4 ميجابايت الذي يحتوي على هذه النتائج على MHZ19 بقدر ما وجدته حتى الآن. هذا واحد يعمل لأسابيع دون مشاكل حتى على gpio 12/14.

سيحاول في المرة القادمة التي يتوقف فيها شيء ما عن العمل ، في الساعة 23:20 وجدت أنه تم تجميد esp18 ، ولم يغير mhzreset ذلك ، انظر السجل أعلاه.

لا يفتح الأمر mhzreset نافذة أوامر في وحدة تحكم الويب ، ولا يبلغ عن موافق أو ما شابه ، بعد عدة محاولات وجدتها في سجل النظام:
<5> 1 2019-02-08T23: 25: 34.164674 + 01: 00 hub18 EspEasy - - - EspEasy: MHZ19: إعادة تعيين مستشعر الإرسال!
<5> 1 2019-02-08T23: 25: 36.313828 + 01: 00 hub18 EspEasy - - - EspEasy: MHZ19: إعادة تعيين مستشعر الإرسال!
من السهل جدًا أن يقول أنه تم إرساله ، لكن يبدو أنه ليس في نكهة يفهمها mhz19 أو تحبها :-)

يبدو أن هذا الأمر يفعل شيئًا لإصدار MH-Z19 A.

127136: MHZ19: Sent sensor reset!
137272: MHZ19: Unknown response: ff ff ff ff ff ff ff ff ff
152275: MHZ19: Unknown response: ff 31 f5 4b 42 32 30 30 d
167277: MHZ19: Bootup detected! PPM value: 5000 Temp/S/U values: 23/1/15000.00
197279: MHZ19: Bootup detected! PPM value: 400 Temp/S/U values: 23/1/15000.00
<repeat a few times>
257279: MHZ19: PPM value: 906 Temp/S/U values: 24/64/11554.00

لذلك يبدو أنه لا يمكن استخدامه على الإصدار B.

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

لم أر إخفاقات حتى بعد ظهر اليوم:
15:43 esp08 مجمدة مرة أخرى ، مجموع اختباري للعدادات (اجتياز / فشل): | 2316/2 وضع مدونة النظام جانبًا.

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

نعم حتى ESP_Easy_mega-20181231_normal_ESP8266_4096 كان ولا يزال جيدًا ،
كانوا يركضون لأسابيع دون مشاكل

لقد بحثت في التغييرات الأخيرة في مكتبة SWserial ، نظرًا لأن هذا هو التغيير الذي نستخدمه الآن.
كان أحد التغييرات التي تم إجراؤها هناك هو عدم استخدام المقاطعات في عمليات نقل TX لـ 9600 باود.
هل يمكنك تجربة بناء هذا الاختبار ؟

قام NB I أيضًا بإزالة الإنشاءات الأساسية 2.5.0 ، نظرًا لأنها تتصرف بشكل غريب عند تقديم صفحات الويب.

Esp08 و Esp18 يقومان بتشغيل ESP_Easy_mega-20190202-82-PR_2235_normal_ESP8266_4096.bin
يرسل هذان الشخصان أيضًا بياناتهما إلى خادم سجل نظام حتى يتم تسجيل بيانات السجل

سيتبع الاثنان الآخران غدًا ، قد يكون أحدهما Mhz19A ، وهو كذلك.

تم تكوين Hw الآن:
يحتوي Esp01 على MHZ19A عند gpio0 / gpio2
يحتوي Esp02 على MHZ19B عند gpio0 / gpio2
يحتوي Esp08 على MHZ19B عند gpio12 / gpio14
يحتوي Esp18 على MHZ19B عند gpio12 / gpio14

كل منهم في نفس الإصدار التجريبي من esp-easy الآن ، يعمل على:
ESP_Easy_mega-20190202-82-PR_2235_normal_ESP8266_4096.bin

تحديث

تم تجميد esp08 06:01 مرة أخرى ، وفقدت العدادات (تسبب المستخدم) في وضع سجل النظام جانبًا.

05:21 Esp18 مجمدة ، المجموع الاختباري (نجاح / فشل): | 1460/0 ، وضعنا سجل النظام جانبًا
12:53 Esp08 مجمدة ، المجموع الاختباري (اجتياز / فشل): | 1351/28 ، وضعنا سجل النظام جانبًا

لم يتم تضمين البنية الأساسية 2.4.1 في بناء الاختبار هذا ، لذلك قمت للتو بإنشاء واحد يحتوي على هذا الإصدار الأساسي فقط. الأساسية 2.4.1 بناء من نفس الكود كما في ESP_Easy_mega-20190202-82-PR_2235_normal_ESP8266_4096.bin
يستخدم هذا الإصدار إصدارًا قديمًا من مكتبة SoftwareSerial.
إذا كان هذا يعمل ، فسوف أقوم بتغيير مكتبة SW التسلسلية المستخدمة.

بدء الترقية إلى الإصدار الخاص: firmware.bin لجميع العقد الأربعة الآن ، انتهى في الساعة 12:30

أول شيء لاحظته ، تم تجميد Esp08 ، وأعاد تحديث البرنامج الثابت هذا تشغيل MHZ19B ، وعاد بشكل كامل ، وهو الحرف الأول الذي أعنيه: المستشعر يعطيني قيمة C02 معقولة ، وهذا يبدو أسرع بكثير أيضًا

أقوم بتشغيل مكتبة SWserial القديمة على عقدة اختبار أيضًا وهي تعمل بشكل أفضل بالفعل
على سبيل المثال ، كانت مراقبة الطاقة في Eastron بها حوالي 20 - 30 ٪ من الخطوط المستلمة تالفة ، ولكن هذا يعمل الآن بشكل مثالي. (لا توجد مجاميع اختبارية فاشلة حتى الآن)

لقد قمت للتو بإنشاء اختبار جديد قمت فيه بتغيير الكثير فيما يتعلق بالغلاف التسلسلي HW / SW.
إنه يعمل الآن مع المكون الإضافي Eastron لكل من SWserial و HW serial و SWserial يستخدم الآن المكتبة القديمة التي استخدمناها حتى 20180131.

إذن هذا هو في الواقع نفس الإصدار 0202 ولكن مع نفس lib التسلسلي مثل إصدار 20181231 ، سأقوم بترقيتهم مباشرة .. فقط لحظة

تم تثبيت ESP_Easy_mega-20190212-73-PR_2235_normal_ESP8266_4096.bin
في Esp0 / 02/08/18 الآن

دعنا نرى ..

نعم ولديها غلاف HWserial / SWserial ، لذلك يجب أن يكون من السهل التبديل إلى HWserial بمجرد استخدام المسامير الصحيحة لهؤلاء.

ما زلت بحاجة إلى إضافة GPIO2 كخيار إضافي لـ HWserial0 ولا يزال هناك بعض التنظيف الذي يجب القيام به في الكود.

مع مرور الساعات الأولى ، ما زالوا يعملون ، بعد التحديث الأخير لا يمكنني رؤية أي شيء غير معروف
استجابة ff 7 × 0 أو 8 مرات 0 رسائل في سجل النظام من esp08 أو esp18 بعد الآن.

استغرق بعض الوقت للنظر في بيانات سجل النظام الخاصة بالعقدتين:
لا يزال لدى Esp08 استجابة غير معروفة برموز متغيرة من حين لآخر ،
لم ينتج Esp18 أي أخطاء بعد

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

مع المكون الإضافي Eastron (إرسال الكثير من البيانات) ، تم تقليل عدد أخطاء المجموع الاختباري بشكل كبير.
من حوالي 20 - 30٪ أخطاء CRC في الرسائل إلى ما يقرب من 0. (خطأ واحد في 10000 رسالة) باستخدام SWserial.

لا تزال تعمل بشكل جيد ، كل أربعة منهم

بالنظر إلى القائمة الثابتة للإصدار 20190215 ، هل هذا الإصدار الآن هو نفس الإصدار الذي أقوم بتشغيله على عقد قياس 4 Co2 هنا؟

غالبا نفس الشيء.
على الأقل رمز المنفذ التسلسلي والمكوِّن الإضافي الخاص بك هو نفسه.

ثم أتركه كما هو وأواصل الاختبار باستخدام "Special"

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

نعم ، كانت العلاقات العامة الكبيرة التي دمجتها بالأمس مصدر جميع عمليات الإنشاء التجريبية التي أجريتها في الأسابيع الماضية.

تم تجميد Esp08 في 14:17 ، المجموع الاختباري للعدادات (اجتياز / فشل): | رقم 3292/70 ، تم وضع سجل النظام جانباً لمزيد من التحليل

وهل إعادة تشغيل بسيطة (أو حفظ الإعدادات) للعقدة أعادت تشغيل المستشعر (وليس إيقاف التشغيل)؟

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

تم تجميد Esp08 مرة أخرى ، المجموع الاختباري للعدادات (اجتياز / فشل): | 2660/55

حفظ معلمات جهاز co2 حل التجميد!

تم تجميد Esp08 18:18 مرة أخرى ، تدقيق العدادات (اجتياز / فشل): | 2660/55

حفظ معلمات جهاز co2 حل التجميد!

حسنًا ، لذلك من الممكن إجراء إعادة تعيين.
سأضيف فحصًا لـ N من الاستجابات غير المعروفة ، ثم أقوم بتنفيذ الأمر init مرة أخرى.

هذا قد يحل هذه المشكلة تماما

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

ترقية الكل إلى ميجا 201902026 4 ميجا بايت الآن.

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

هذا يبدو حقا واعدا! كنت أشاهد هذا الموضوع ، في انتظار لحظة يمكنني أخيرًا الترقية. : ابتسامة: لدي عقدة مرفقة بكل من MH-Z19 و PMS7003. كان MH-Z19 يعمل> 90٪ من الوقت ولكن في بعض الأحيان كان علي إعادة تعيين ESP لذلك.

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

ونعم ، لقد لاحظت أن الرقم # 2349 قد لمست رمز MH-Z19 فقط ولكن البنية التي أقوم بتشغيلها هي "20100 - Mega (core 2_4_0)" والتي أفترض أنها قديمة جدًا.

أريد أن أقول إنه من النادر رؤية مثل هذا الإصرار من كلا الجانبين في قضية ما. أعتقد أن الكثيرين كانوا سيستسلمون بعد أيام قليلة. القبعات لك من هذا المتفرج @ TD-er وpwassink!

قد ترغب في الانتظار لمدة يوم آخر قبل الترقية.
أنا أعمل الآن على بعض التصحيحات للاتصال بالشبكة.

شكرا للمعلومة! كنت أخطط لانتظار تقارير pwassink للحظة على أي حال (كسول).

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

أخذت الملاحظة. لا أستطيع إلا أن أتخيل صعوبة تجنب الانحدار في نظام مثل ESPEasy. سأقوم بالإبلاغ عن أي تراجع بعد أن أقوم بالترقية (كمشكلات منفصلة بالطبع).

أنا أخطط لترقية اثنين من ESP لدي هنا. بناءً على أولئك الذين يمكنني فقط ملاحظتهم إذا كان هناك تراجع في التعامل مع شاشة MH-Z19 أو PMSx003 أو BMx280 أو TSL2561 أو DHT22 أو OLED SSD1306. يميل TSL2561 الموجود على ESP الآخر إلى إيقاف إرجاع البيانات بشكل عشوائي أيضًا (على الرغم من أنه نادر جدًا). يتم تشغيل بناء "20102 - ميجا".

هذا ليس الإصدار ، ولكن تنسيق الملف الداخلي (محيرًا أعلم) قد تجد اسم / تاريخ الإصدار في صفحة sysinfo.

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

لا بناء الطابع الزمني في صفحة sysinfo؟

هناك طابع زمني ولكنه لن يساعد كثيرًا لأنني لا أتذكر ما إذا كنت قد قمت بسحب أحدث رمز قبل القيام بذلك. لكنه بالطبع يعطي بعض التأييد.

هذا ليس برنامج ESP الذي يستضيف MH-Z19 و PMS7003.

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

ما هو الإصدار الذي تم إصلاح هذا فيه؟

بعد بضع ساعات أحصل على MHZ19: استجابة غير معروفة: 0 0 0 0 0 0 0 0 0
إعادة التشغيل لن تصلحها يجب فصلها وتوصيلها مرة أخرى

أنا أستخدم wemos 1d mini pro ، فهل يحتوي هذا الإصدار على الإصلاح فيه؟

بناء: ⋄ | 20104 - ميجا
- | -
مكتبات النظام: ⋄ | ESP82xx Core 2_5_2، NONOS SDK 2.2.1 (cfd48f3)، LWIP: 2.1.2 دعم PUYA
Git Build: ⋄ | ميجا 20191003
الإضافات: ⋄ | 46 [عادي]
بناء Md5: | 3180a4d3e118166b3414444513a6169
فحص Md5: | تم الاجتياز بنجاح.
وقت البناء: ⋄ | 3 أكتوبر 2019 02:15:29
اسم الملف الثنائي: ⋄ | ESP_Easy_mega-20191003_normal_ESP8266_4M1M.bin

شكرا

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

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

على سبيل المثال إحدى الوحدات الخاصة بي (مدة تشغيل لمدة 3 أيام)

ملاحظة: لا يوجد معنى للمرشح (الذي تم ضبطه على "استخدام غير مستقر" في لقطة الشاشة) على مستشعر MH-Z19B ، فهو قابل للتطبيق فقط للإصدار -A.

وواحدة أخرى:

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

عمليات إعادة التعيين الـ 11 هذه حيث أحاول إعادة تشغيله مرة أخرى دون إعادة إدخاله وإخراجه ، لا أتذكر أي أخطاء على الرغم من أنني يمكنني إعطائها لقطة أخرى ، فهل يجب أن أستخدم Software Serial؟

تسلسل الأجهزة هو الأفضل ، ولكن يجب عليك أيضًا تعطيل المنفذ التسلسلي في Tools-> Advanced-> Serial Port. (كما هو مذكور في لقطة الشاشة الخاصة بك :))

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

البناء: ESP_Easy_mega_20201130_normal_ESP8266_4M1M
تقديم التقارير إلى FHEM.
واجهت مشكلة مماثلة: يتجمد مستشعر MH-Z190B كل بضع ساعات ويستمر في الانخفاض إلى 400 عند استخدام المسلسل للأجهزة.
بعد التبديل إلى البرنامج التسلسلي ، يبدو أنه يعمل بشكل طبيعي ولا يتجمد بعد الآن.
عدد 2 لقطة شاشة مرفقة.

يعمل الطراز BME280 المرفق بـ I2C بشكل جيد ويستمر في الإبلاغ طوال الوقت

حسنًا ، هذا غريب.
إلى أي منفذ تسلسلي HW تم توصيله؟
ماذا متصل باللوحة؟ (على سبيل المثال USB إلى شريحة تسلسلية)
هل "Use Serial" غير محدد في صفحة Tools-> Advanced؟

إنه متصل بـ GPIO-13 (D7) <- TX و GPIO-15 (D8) -> RX (أولًا في HW الآن في SW) حيث أردت استخدام TXD0 و RXD0 لقراءة الرسائل عبر منفذ USB (CH340 ) من Wemos D1 mini.
هل تعني عبارة "Use Serial" (استخدام المسلسل) "Serial Settings - Enable Serial Port:" محددًا؟ تركت هذا محددًا لأتمكن من قراءة الرسائل بواسطة USB.

يستخدم المسلسل HW على ESP8266 Serial0.
إذا قمت أيضًا بإرسال سجلات إلى نفس المنفذ التسلسلي ، فقد يتعطل المستشعر لأنه لا يفهم "الأوامر" التي يتلقاها عند إرسال السجلات عبر هذا المنفذ.

إذا قمت بتوصيل شيء ما بمنفذ HW التسلسلي ، فلا يجب عليك بعد الآن إرسال بيانات أخرى. وبالتالي يجب عليك تعطيل "Use Serial" في صفحة الأدوات> Advanced.

بالأمس ، حصلت على جهاز استشعار آخر MH-Z19C. يبدو أن هذا الجهاز يعمل بشكل جيد مع HW-Serial على Serial2. نظرًا لأن جميع المستشعرات كانت متصلة بـ Pins D7 (GPIO 13) و D8 (GPIO 13) (RXD2 و TXD2) فلا ينبغي أن يكون هناك أي تعارض مع Serial0 (Pins RXD0 (GPIO3) و TXD0 (GPIO1)) بقدر ما أنا فهم Pinout. أعتقد أن المستشعر الأول (MH-Z19B من مورد آخر) كان مجرد مستشعر مزيف لا يعمل بشكل صحيح على الإطلاق ، ...
لذا كن حذرًا عند شراء تلك المستشعرات. الثاني ، الذي حصلت عليه بالأمس كان في عبوة أفضل بكثير مع شعار Winsen وانضمت شهادة اختبار. يبدو أن المورد أكثر جدية من الذي باع لي الأول.