मेरे द्वारा हाल ही में बनाए गए सीरियल में हुए बदलाव से संबंधित लगता है।

आप किस gpio पिन का उपयोग करते हैं?

यह हो सकता है, देखते हैं, मुझे लगता है कि आपको एक बिंदु मिल गया है Gijs :-)

esp01 = Gpio0 Gpio2 (अभी तक कोई समस्या नहीं देखी गई)
esp02 = Gpio14 Gpio12
esp08 = Gpio14 Gpio12
esp18 = Gpio14 Gpio12

पीटर

मेरे यहां दो नोड हैं, मैं आज दोपहर बाद में भी परीक्षण कर सकता हूं

ठीक,
गलती तत्काल नहीं है, वे थोड़ी देर के बाद भेजना बंद कर देते हैं, और उसमें काफी हद तक कायम रहते हैं, फिर से डेटा भेजने के लिए रीबूट या स्व डाउनग्रेड पर्याप्त नहीं है। उन्हें एक पावर साइकिल और ऑफ और ऑन के बीच कुछ समय चाहिए।

"थोड़ी देर बाद" कब तक है?
मैंने इनमें से किसी एक सेंसर का उपयोग करके अभी एक नोड सेटअप किया है और एक BMP280 भी जुड़ा हुआ है।
यह CO2 सेंसर के लिए GPIO-14 और -12 का उपयोग कर रहा है।

कुछ घंटे, कल सब कुछ काम कर रहा था, आज सुबह मेरे पास 4 में से 3 समान स्थिति के साथ थे।

और वे सभी एक ही समय के आसपास बूट हो गए, इससे पहले कि वे सभी काम करना बंद कर दें?

हां, मुझे लगता है कि एक घंटे के भीतर सभी को पुनरारंभ/अपडेट किया गया था, कल शाम उन्हें अपडेट कर रहा था। और रात में उन्होंने काम करना बंद कर दिया

मैं बस अपने नोड्स को अपडेट करने वाला था लेकिन सौभाग्य से इस पर ध्यान दिया। @ टीडी-एर जो आपके द्वारा अनुमान लगाए जा रहे सीरियल में बदलाव से पहले नवीनतम रिलीज होगी, वह अपराधी हो सकता है? या क्या यह अधिक उपयोगी होगा यदि मैं नवीनतम संस्करण को फ्लैश करके देखूं कि क्या मुझे एक ही समस्या का अनुभव होगा?

यदि कोई लापता अपडेट कोई बड़ी बात नहीं है, तो मैं नवीनतम संस्करण का सुझाव दूंगा।
सीरियल पोर्ट रैपर से पहले के संस्करण को जारी रखने के लिए, आप 20181231 का उपयोग कर सकते हैं। (मुझे लगता है कि मैंने इस साल बदलाव किए हैं)

मैंने कल 3 "समस्या" esp को 20181231 में डाउनग्रेड किया था, पुष्टि कर सकता है कि वे अभी भी बिना किसी हार्डवेयर परिवर्तन के डेटा भेज रहे हैं, अब 24 घंटों के लिए तो उन तीन esp अभी भी मेरे मामले में gpio12 और gpio14 का उपयोग कर रहे हैं

गिज्स को फिर से बनाने के साथ कोई भाग्य?

नहीं, मेरा नोड अभी भी मान भेज रहा है और यह 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 और फिर से प्रदर्शित कर रहा है। Logfile में समान प्रविष्टियों के साथ:
MHZ19: पढ़ने की कोशिश करते समय त्रुटि, समयबाह्य
MHZ19: अज्ञात प्रतिक्रिया: 0 0 0 0 0 0 0 0 0

Esp-18 Gpio 14 / 12 . का उपयोग कर रहा है
यह ali . से Ch340 संस्करण 2 के 3 के साथ एक Nodemcu है
वेब कंसोल के माध्यम से रिमोट रीबूट ने समस्या का समाधान नहीं किया
फिर से यह ऊपर वर्णित उन प्रविष्टियों को कई बार प्रदर्शित कर रहा है
बिजली चक्र के बाद
78640: MHZ19: त्रुटि, पढ़ने का प्रयास करते समय समयबाह्य
78641: MHZ19: त्रुटि पढ़ें: चेकसम = 202/0 बाइट्स पढ़ें => 255/168/12/161/226/255/0/0/0/
78643: MHZ19: बफर संरेखण को ठीक करने के प्रयास के लिए 1 बाइट्स को स्थानांतरित किया गया
कुछ और समय के बाद:
255652: एमएचजेड19: पीपीएम मान: 1584 अस्थायी/एस/यू मान: 25/0/0.00
255656: घटना: रिक-सीओ2#पीपीएम=1584.00
255656: घटना: रिक-सीओ2#पीपीएम=1584.00 प्रसंस्करण समय: 1 मिलीसेकंड
255659: घटना: रिक-सीओ2#तापमान=25.00
255659: घटना: रिक-सीओ2#तापमान=25.00 प्रसंस्करण समय: 1 मिलीसेकंड
255662: घटना: रिक-सीओ2#यू=0.00
255662: घटना: रिक-सीओ2#यू=0.00 प्रसंस्करण समय:1 मिलीसेकंड

ऐसा लगता है कि यह अब फिर से काम कर रहा है, लेकिन बिजली की जरूरत है लगभग 2 मिनट बिजली नहीं

क्या उस समय कुछ करने की जरूरत है? क्या कुछ ऐसा हो सकता है जिससे ईएसपी पर वाईफाई की हिचकी आ सकती है?

कुछ भी नहीं,

उस समय कोई अनुसूचित रीसेट, रिबूट, बैकअप, डब्ल्यूएफआई रीसेट, डीएचसीपी क्लीनअप या कोई बाहरी कारण नहीं है

और वाईफाई ठीक काम करता रहता है यह सिर्फ mhz19 का रीडआउट है जो रुक जाता है, अन्य सभी (i2c आधारित) सेंसर एक ही esp पर काम करते हैं

आज सुबह 03:00 बजे यह फिर से Esp-18 के साथ 0121 मेगा संस्करण चलाने के साथ हुआ, esp-logfile में पहले की तरह ही त्रुटियाँ, अन्य सेंसर ठीक काम करते हैं

और 19:05 पर ESP_Easy_mega20190116_normal_core_241_ESP8266_4096.bin के साथ चलने वाला esp02 भी क्रैश हो गया, ऊपर की तरह ही स्थिति, अब कोई डेटा नहीं और लॉगिंग में समान प्रविष्टियाँ।

आज फिर 2 हिचकी, 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 मिनट है
बिजली गुल होने के बाद से...
यह CO2 मान के नियमित अपडेट के साथ ठीक चल रहा है।

मैं करूंगा,

लेकिन क्या मैंने पहले ही इसका उल्लेख किया है कि संस्करण मेगा 20181231 कोर 2.4.1 सामान्य 4Mb तक रिपोर्ट की गई स्थिरता के मुद्दों में से कोई भी नहीं देखा गया है, तो यह विशिष्ट संस्करण क्यों है?

मैं उस विशिष्ट संस्करण को eesp02 और esp18 co2-मापने वाले नोड्स में स्थापित करने के लिए डाउनलोड करूंगा, लेकिन मेरी विनम्र राय में समस्याएं मेगा-2019* रेंज में पहले नहीं दिखाई दीं।

ठीक है, तो यह वास्तव में किसी काम का नहीं है।

वह विशिष्ट संस्करण मेरे पास एक संस्करण पर चल रहा है जो (दुख की बात है असामान्य) स्थिर प्रतीत होता है।
और आप सही कह रहे हैं, अगर यह 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 भी भेजना बंद कर दिया।

लॉग स्निपेट
370508579: यूडीपी: 60:01:94:0F:AF:9D,192.168.3.46,17
370508785: यूडीपी: 24:0A:C4:82:F2:B8,192.168.3.51,21
370509501: यूडीपी: 60:01:94:0सी:2ई:एफडी,192.168.3.48,19
370514624: यूडीपी: 5सी:सीएफ:7एफ:82:एफडी:47,192.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: यूडीपी: 60:01:94:0बी:94:5सी,192.168.3.30,1
370520460: यूडीपी: 60:01:94:02:0E:E8,192.168.3.36,7
370523940: यूडीपी: 18:एफई:34:ई2:18:84,192.168.3.35,6
370529880: यूडीपी: बीसी:डीडी:सी2:ईए:3डी:बीसी,192.168.3.54,24

यह गलती मैंने पहली बार देखी है, शायद..

एक चेकसम त्रुटि को और अधिक सुंदर ढंग से संभाला जाना चाहिए।
हो सकता है कि हमें नई अच्छी शुरुआत की तलाश में शिफ्टिंग शुरू करने के लिए कुछ सीमा जोड़नी चाहिए।
या फिर से सिंक करने के लिए एक बेहतर एल्गोरिदम।
जहां तक ​​मुझे पता है, पिछले एक साल में इसके लिए कोड में कोई बदलाव नहीं किया गया है। सीरियल पोर्ट कनेक्शन बनाने के तरीके में केवल एक बदलाव आया है, इसलिए मैं वास्तव में नहीं जानता कि यह इन मुद्दों की ओर क्यों ले जाता है।

मेरे पास यह विचार है कि mhz19 सेंसर कुछ घंटों के गलत संचार के बाद या डेटा प्राप्त करने में सक्षम नहीं होने के परिणामस्वरूप "अवरुद्ध" स्थिति में प्रवेश करता है। ?
प्रेरणा: एक रिबूट या यहां तक ​​​​कि एक पूर्ण स्व-अपडेट उस स्थिति को हल नहीं करता है, mhz19 को जीवन को पुनः प्राप्त करने के लिए एक या एक मिनट के लिए शक्तिहीन होना पड़ता है, मुझे यह व्यवहार तब मिला जब यह उस स्थिति में फंस गया जो इस तरह दिखता है:
MHZ19: पढ़ने की कोशिश करते समय त्रुटि, समयबाह्य
MHZ19: अज्ञात प्रतिक्रिया: 0 0 0 0 0 0 0 0 0

गलती esp08 आज सुबह वेब कंसोल से रिमोट रीबूट विकल्प के साथ हल करने योग्य थी, इसलिए यह कई घंटों के बाद पूर्ण लॉकअप जैसा नहीं था और मैंने दो बार रिपोर्ट की थी।

लेकिन बाद में यह मिला:
लगभग 1800 स्थानीय समय पर यह अवरुद्ध स्थिति में चला गया, रीसेट, कंसोल पॉवरसाइकिल के माध्यम से रिबूट इस बार कुछ भी काम नहीं किया, डिवाइस को मेगा 20181231 4एमबी संस्करण के साथ फिर से फ्लैश की जरूरत थी, फिर यह फिर से जीवन में आया। Esp08 Gpio12/14 संयोजन का उपयोग कर रहा है और यह एक nodemcu v2 ch340 मॉडल भी है

यह काफी अजीब लगता है, क्योंकि प्लगइन MH-Z19 को नया सेंसर डेटा इकट्ठा करने के लिए एक कमांड भेजता है
तो मुझे समझ में नहीं आता कि सॉफ्ट-रीबूट भी काम क्यों नहीं कर रहा है।
मैं यह देखने के लिए कुछ आँकड़े भी जोड़ूंगा कि चेकसम त्रुटि कितनी बार होती है (अंत प्राप्त करना)
यदि ऐसा बहुत होता है, तो यह सेंसर को डेटा भेजते समय भी हो सकता है और हो सकता है कि सेंसर को फिर किसी अज्ञात कमांड मोड में डाल दिया जाए।
हो सकता है कि कुछ पुल-अप रेसिस्टर कॉन्फ़िगरेशन बदल गया हो जब मैंने सीरियल पिन को कॉन्फ़िगर करने का तरीका बदल दिया हो ???

ये हो सकता है,

कल इसे थोड़ा और देखेंगे या आने वाले सप्ताहांत के दौरान शायद मैं कुछ ढूंढ पाऊंगा, क्या वह सेंसर व्यापक रूप से उपयोग नहीं किया जाता है कि कोई भी समान व्यवहार नहीं करता है?

या नवीनतम बिल्ड चलाने वाले लोगों द्वारा उपयोग नहीं किया जाता है

मेरे पास 2 MH-Z19b हैं, दोनों बिना किसी समस्या के 20190116 टेस्ट बिल्ड पर चल रहे हैं

ठीक है, बस उत्सुक है कि परीक्षण का कौन सा कोर-संस्करण निर्माण करता है और आप किस जीपीओ का उपयोग कर रहे हैं?

मैं देख रहा हूं कि 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 . से जुड़े दोनों सेंसर पर

तो यह एक और कोर और एक अन्य जीपीआईओ है जिसे आप जीपीआईओ 14/12 के बजाय 13/12 में उपयोग कर रहे हैं मैं यहां उपयोग करता हूं

आज मैंने 4 में से 4 को ESP_Easy_mega-20190202_normal_core_241_ESP8266_4096.bin संस्करण में अपडेट किया

आइए देखते हैं

अब जब मैं इसके बारे में सोचता हूं, तो इस साल की शुरुआत से इस्तेमाल की गई SWserial लाइब्रेरी में एक और बदलाव हो सकता है।
हमारे पास SWserial लाइब्रेरी का अपना संस्करण हुआ करता था, जिसे मैंने कम iRAM मेमोरी का उपयोग करने के लिए पैच किया था।
लेकिन अब हम कोर लाइब्रेरी में शामिल संस्करण का उपयोग कर रहे हैं और कोर 2.5.0 के लिए यह पहले की तुलना में एक नया संस्करण हो सकता है।
साथ ही लो-स्पीड कनेक्शन पर इंटरप्ट के इस्तेमाल में भी कुछ बदलाव हो सकता है। (9600 बॉड और निचला)
मुझे उस पर भी गौर करना चाहिए।

यह अभी भी स्पष्ट नहीं करता है कि सेंसर स्पष्ट रूप से इतना गड़बड़ क्यों हो सकता है कि उसे फिर से सामान्य कार्य करने के लिए पावर-डाउन की आवश्यकता होती है।

ESP_Easy_mega-20190202_normal_core_241_ESP8266_4096.bin पर अपडेट करने के 3 घंटे के भीतर मेरा esp18 फिर से लॉक हो गया, वेब कंसोल रिबूट काम नहीं किया, फिर से पावरडाउन की आवश्यकता थी।
दूसरा अभी भी काम कर रहा है, अगर यह MHZ19 को भी जमा देता है तो यहां जोड़ देगा

हां, दूसरे esp18 ने आज शाम 19:05 पर उचित CO2 डेटा भेजना बंद कर दिया, इसलिए कल के मेगा 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-change के बाद भी जीवित रहता है।
पूर्ण

मैंने अभी पठन में कुछ सुधार करने के लिए एक प्रतिबद्धता जोड़ी है।
देखें https://github.com/TD-er/ESPEasy/commit/3d507bdbb9dc6dd4aee2ce0c7ce6c809ea7dfb7c

क्या आप इसके लिए एक परीक्षण संस्करण बना सकते हैं, या क्या आप चाहते हैं कि मैं एक का निर्माण करूँ?

यदि आप मुझे एक बिन प्रदान कर सकते हैं तो मुझे इसे gpio12/14 रनिंग esp दोनों पर रखकर खुशी होगी
और फिर यह निश्चित है कि फ़ाइल वही है, कोई स्थानीय प्रभाव नहीं आदि ..

ठीक है, कुछ समय लगा, लेकिन यहाँ परीक्षण निर्माण है

समझ लिया,

Esp08 और esp18 अब इस टेस्ट वर्जन पर 2.4.1 कोर के साथ चल रहे हैं, वे दोनों gpio12/14 का उपयोग करते हैं

आइए देखते हैं !

आपको संसाधित लाइनों की संख्या और सीआरसी विफलताओं की संख्या दिखाने वाला कुछ संकेतक भी देखना चाहिए

हाँ, मेरे पास अब कंसोल में भी है!

उन 2 को छोड़ देंगे और निश्चित अंतराल पर देखेंगे कि क्या वे काउंटर बढ़ते हैं।
आप तैनात रहेंगे ..

परीक्षण नोड्स में उपयोग में आने वाले दोनों सेंसर B संस्करण हैं ताकि पता लगाने ने भी काम किया

चेकसम (पास/असफल): | 11/0
-- 08 --
पता चला: | एमएच-जेड19बी

चेकसम (पास/असफल): | 8/0
-- 18 --
पता चला: | एमएच-जेड19बी

क्या आपके पास MH-Z19 A/B या केवल नए B संस्करणों का मिश्रण है?
कोई बात नहीं होनी चाहिए, बस जिज्ञासु।

क्या आपके पास MH-Z19 A/B या केवल नए B संस्करणों का मिश्रण है?
कोई बात नहीं होनी चाहिए, बस जिज्ञासु।

बी संस्करण, बस उस जानकारी को जोड़ा, पहचान ने भी काम किया :-)

छोटे अपडेट, सभी अभी भी ठीक चल रहे हैं, आपके विशेष संस्करण esp8 और 18 वाले बढ़ते काउंटर दिखाते हैं लेकिन फिर भी कोई दोष या चेकसम त्रुटियां नहीं हैं, वर्तमान मान हैं:

Esp08: चेकसम (पास/असफल): | 1795/0
Esp18: चेकसम (पास/असफल): | 724/0

और दूसरा जो काफी सुसंगत esp02 में विफल रहा, वह अब भी बदले हुए Gpio के साथ चल रहा है
और इस प्रकार di-mini में अब Gpio-0/Gpio-2 पर mhz19 और मेगा 20190202 संस्करण कोर 2.4.1 है।

बमर ने गलती से यहां पोस्ट को हटा दिया, मेरी स्मृति को फिर से बनाने का प्रयास करें:

कल शाम मेरे esp के 02, 08 और 18 में से तीन Domoticz पर लाल हो गए, कोई Co2 सेंसर डेटा नहीं।
उनमें से दो का विशेष संस्करण कोर 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 के समान है) दोनों ठीक नहीं हुए, और आज सुबह दोनों को 2 मिनट का पावर-डाउन मिला, उसके बाद दोनों जीवन में वापस आ गए।

मैंने अब esp02 पर सॉफ़्टवेयर-संस्करण को ESP_Easy_mega-20190202-58-PR_2235_normal_core_250_beta_ESP8266_4 में बदल दिया है ताकि हम उस कोर-संस्करण का भी परीक्षण कर सकें, gpio chnage ने पुराने (वर्तमान 2.4.1) संस्करण को चलाने में कोई अंतर नहीं किया।
esp02 ने आज एक एकल चेकसम विफलता दिखाई: चेकसम (पास/असफल): | 79/1

मैंने शुरुआत में केवल esp08 के लिए syslog को सक्रिय किया, नीचे सेटिंग्स के साथ, यदि आप एक विशिष्ट सेटिंग चाहते हैं तो कृपया पूछें।

हो सकता है कि आप पोस्ट में अपने कॉन्फिग को भी आइटम कर सकते हैं (अगली पोस्ट भी हो सकती है, इसे संपादित करने की कोई आवश्यकता नहीं है) निम्नलिखित दिखा रहा है:

• आपकी आंतरिक इकाई संख्या (आपके अपने संदर्भ के लिए जैसे "02, 08, 18)
• बिल्ड रनिंग
• सफलता/असफलता का एनआर (यदि उपलब्ध हो)
• विफलता/समस्या का प्रकार

विवरणात्मक पाठ की तुलना में मदबद्ध जानकारी (मेरे लिए) अनुसरण करना आसान है।
मैं भी कभी-कभी अपने फोन से रिप्लाई करता हूं।

esp08/18 ESP_Easy_mega-20190202-58-PR_2235_सामान्य_ESP8266_4096 कोर 2.4.1 gpio12/14
esp01/02 ESP_Easy_mega-20190202-58-PR_2235_normal_core_250_beta_ESP8266_4096 gpio 0/2

-- जमे हुए का अर्थ है co2 रीडिंग को छोड़कर ठीक काम करना

22:57 esp08 फिर से जमे हुए, काउंटर चेकसम (पास/असफल): | 1077/2 मिलने पर syslog को एक तरफ रख दें।
05:05 esp18 फिर से जमे हुए, काउंटर चेकसम (पास/असफल): | 1076/2
06:25 esp08 फिर से जमे हुए, कोई काउंटर नहीं, esp इस बार पूरी तरह से क्रैश हो गया, syslog मिला
12:57 esp18 फिर से जम गया। काउंटर चेकसम (पास/असफल): | 116/2
20:43 esp18 फिर से जमे हुए, काउंटर चेकसम (पास/असफल): | 316/2 ने mhzreset कमांड की कोशिश की
अब तक कोई बदलाव नहीं, सेंसर mhz19 अज्ञात प्रतिक्रिया भेज रहा है 0 0 0 0 0 0 0 0
बार-बार संदेश, कई प्रयासों का कोई समाधान नहीं, पावर ने नोड को साइकिल किया।

गिज,

मैंने esp08 के अंतिम syslog पर कुछ विश्लेषण किया था, जो घंटों चल रहा था, मैंने 78 घटनाओं को देखा:
2019-02-08T05: 27: 07.581181+01:00 हब08 EspEasy - - - EspEasy: MHZ19: अज्ञात प्रतिक्रिया: ff 0 0 0 0 0 0 0 0

#cat संदेश-क्रैश-esp08-0625 |grep MHZ19 | . का उपयोग करके स्वचालित खोज जीआरपी प्रतिक्रिया | ग्रेप 'एफएफ 0 0 0 0 0 0 0 0' | डब्ल्यूसी-एल

और उस cmdline को दूसरे अज्ञात-प्रतिक्रिया संस्करण linux में बदलने के बाद इस पंक्ति की 408 बार गणना की गई:
2019-02-08T10:44:06.855432+01:00 हब08 EspEasy - - - EspEasy: MHZ19: अज्ञात प्रतिक्रिया: 0 0 0 0 0 0 0 0 0

आपके कस्टम-डीबग-संस्करण में चेकसम त्रुटि काउंटरों को 2 से अधिक नहीं मिला, जैसा कि मैंने पिछले कुछ दिनों के दौरान देखा था।
पहला त्रुटि संदेश (MHZ19: अज्ञात प्रतिक्रिया: ff 0 0 0 0 0 0 0 0) आज सुबह जमने से पहले छह बार या तो सीधे एक दूसरे के बाद आया।

ऐसा लगता है कि सेंसर ही क्रैश हो रहा है, लेकिन मैं इसका कोई कारण नहीं सोच सकता कि यह अभी ऐसा क्यों कर रहा है।
हमारे स्रोत में MH-Z19 सेंसर के रीसेट को कॉल करने के लिए एक कमांड है, लेकिन यह डेटाशीट में प्रलेखित नहीं है।
इसलिए मुझे इसकी स्थिति की जानकारी नहीं है।
क्या आप उस आदेश को नोड पर कॉल करने का प्रयास कर सकते हैं जो इस तरह फंस गया है?

संपादित करें: वह आदेश mhzreset है

मेगा 20181231 2.4.1 के बाद कुछ बदलाव करने होंगे। 4Mb संस्करण जिसका यह परिणाम MHZ19 पर है जहाँ तक मुझे अभी तक मिला है। वह gpio 12/14 पर भी बिना किसी समस्या के हफ्तों से चल रहा है।

अगली बार जब कुछ काम करना बंद कर देगा तो कोशिश करेंगे, 23:20 पर पाया गया कि esp18 जमी हुई थी, mhzreset ने इसे नहीं बदला, ऊपर लॉग देखें।

mhzreset कमांड वेब कंसोल में कमांड विंडो नहीं खोलता है, ओके बैक या तो रिपोर्ट नहीं करता है, कई प्रयासों के बाद मुझे syslog में मिला:
<5>1 2019-02-08T23:25:34.164674+01:00 हब18 EspEasy - - - EspEasy: MHZ19: भेजा गया सेंसर रीसेट!
<5>1 2019-02-08T23:25:36.313828+01:00 हब18 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

तो ऐसा लगता है कि इसका उपयोग बी-संस्करण पर नहीं किया जा सकता है।

मैं कुछ ऐसा मान सकता हूं कि प्लगइन के स्टार्टअप/इनिट में किसी भी तरह कमांड का उपयोग किया जाता है?
जो समझा सकता है कि बिजली चक्र के बिना रीबूट/रीसेट क्यों समस्या का समाधान नहीं करता है।

आज दोपहर तक नहीं देखी असफलताएं:
15:43 esp08 फिर से जमे हुए, काउंटर चेकसम (पास/असफल): | 2316/2 सिस्टलॉग को एक तरफ रख दें।

और बस यह सुनिश्चित करने के लिए, ये नोड पुराने फर्मवेयर संस्करणों पर ठीक चल रहे थे?

हाँ जब तक ESP_Easy_mega-20181231_normal_ESP8266_4096 था और अभी भी ठीक है,
वे बिना किसी समस्या के हफ्तों तक चलेंगे

मैंने SWserial पुस्तकालय में हाल के परिवर्तनों पर ध्यान दिया, क्योंकि अब हम इसका उपयोग कर रहे हैं।
इसमें किए गए परिवर्तनों में से एक 9600 बॉड के लिए TX स्थानान्तरण पर इंटरप्ट का उपयोग नहीं करना था।
क्या आप इस टेस्ट बिल्ड को आजमा सकते हैं?

NB I ने कोर 2.5.0 बिल्ड को भी हटा दिया, क्योंकि वे वेब पेजों की सेवा करते समय अजीब काम करते हैं।

Esp08 और Esp18 ESP_Easy_mega-20190202-82-PR_2235_normal_ESP8266_4096.bin चला रहे हैं
वे दोनों भी अपना डेटा एक syslog सर्वर पर भेजते हैं ताकि लॉग डेटा रिकॉर्ड किया जा सके

अन्य दो कल का अनुसरण करेंगे, उनमें से एक Mhz19A हो सकता है, और यह है।

Hw config अब है:
Esp01 में gpio0/gpio2 . पर MHZ19A है
Esp02 में gpio0/gpio2 . पर MHZ19B है
Esp08 में gpio12/gpio14 . पर MHZ19B है
Esp18 में gpio12/gpio14 . पर MHZ19B है

उन सभी को esp-easy के एक ही टेस्टवर्जन पर अब चल रहा है:
ESP_Easy_mega-20190202-82-PR_2235_normal_ESP8266_4096.bin

अपडेट करें

06:01 esp08 फिर से जम गया, काउंटर खो गए (उपयोगकर्ता के कारण) syslog को एक तरफ रख दिया।

05:21 Esp18 फ्रोजन, चेकसम (पास/फेल): | 1460/0, syslog को एक तरफ रख दिया है
12:53 Esp08 फ्रोजन , चेकसम (पास/असफल): | 1351/28, syslog को एक तरफ रख दिया है

कोर 2.4.1 बिल्ड को उस टेस्ट बिल्ड में शामिल नहीं किया गया था, इसलिए मैंने केवल उस मूल संस्करण को ही बनाया है। कोर 2.4.1 ESP_Easy_mega-20190202-82-PR_2235_normal_ESP8266_4096.bin के समान कोड का निर्माण
वह SoftwareSerial लाइब्रेरी के पुराने संस्करण का उपयोग करता है।
अगर वह काम कर रहा है, तो मैं इस्तेमाल की गई एसडब्ल्यू सीरियल लाइब्रेरी को बदल दूंगा।

विशेष-संस्करण में अपग्रेड शुरू करना: सभी 4 नोड्स के लिए फर्मवेयर.बिन, 12:30 . पर समाप्त

पहली बात जो मैंने देखी, Esp08 जमी हुई थी, इस फर्मवेयर अपडेट ने MHZ19B को फिर से शुरू किया, यह वापस आ गया, एक init मेरा मतलब है: सेंसर मुझे एक उचित C02 मान दे रहा है यह बहुत तेज लग रहा था

मैं एक परीक्षण नोड पर भी पुराने SWserial पुस्तकालय चला रहा हूँ और वास्तव में यह बहुत बेहतर काम कर रहा है
उदाहरण के लिए, ईस्ट्रॉन ऊर्जा निगरानी में प्राप्त लाइनों का लगभग 20 - 30% दूषित हो रहा था, लेकिन यह अब पूरी तरह से चल रहा है। (अभी तक कोई असफल चेकसम नहीं)

मैंने अभी एक नया टेस्ट बिल्ड बनाया है जिसमें मैंने HW/SW सीरियल रैपर के बारे में बहुत कुछ बदल दिया है।
यह अब SWserial और HW सीरियल दोनों के लिए Eastron प्लगइन के साथ काम करता है और SWserial अब पुरानी लाइब्रेरी का उपयोग कर रहा है जिसका उपयोग हमने 20180131 तक किया था।

तो यह वास्तव में 0202 संस्करण के समान है, लेकिन 20181231 संस्करण के समान सीरियल लिब के साथ, मैं उन्हें सीधे अपग्रेड कर दूंगा .. बस एक पल

स्थापित ESP_Easy_mega-20190212-73-PR_2235_normal_ESP8266_4096.bin
Esp0/02/08/18 पर अभी

आइए देखते हैं ..

हां और इसमें HWserial/SWserial रैपर है, इसलिए जैसे ही आप उनके लिए सही पिन का उपयोग कर रहे हैं, HWserial पर स्विच करना आसान होना चाहिए।

मुझे अभी भी HWserial0 के लिए अतिरिक्त विकल्प के रूप में GPIO2 जोड़ने की आवश्यकता है और कोड में अभी भी कुछ सफाई-अप करना बाकी है।

जैसा कि पहले घंटे बीत चुके हैं, वे अभी भी काम कर रहे हैं, आखिरी अपडेट के बाद मुझे कोई अज्ञात नहीं दिख रहा है
प्रतिक्रिया ff 7 x 0 या 8 गुना 0 संदेश syslog में esp08 या esp18 से अब और।

2 नोड्स के syslog-डेटा को देखने में कुछ समय लगा:
Esp08 में अभी भी एक अज्ञात प्रतिक्रिया है जिसमें अलग-अलग कोड एक बार में एक बार होते हैं,
Esp18 ने अभी तक कोई दोष उत्पन्न नहीं किया है

सुन कर अच्छा लगा।
मुझे लगता है कि हमारे पास कुछ मुद्दे थे जहां सेंसर को भेजा गया डेटा दूषित हो गया था।
तब सेंसर स्वयं दुर्घटनाग्रस्त हो सकता है, मुझे लगता है।

ईस्ट्रोन प्लगइन के साथ (बहुत अधिक डेटा भेजना) चेकसम त्रुटियों की संख्या में काफी कमी आई थी।
संदेशों में लगभग 20 - 30% सीआरसी त्रुटियों से लगभग 0. (10’000 संदेशों में 1 त्रुटि) SWserial का उपयोग कर।

अभी भी ठीक चल रहा है, चारों

रिलीज़ 20190215 की निश्चित-सूची को देखा, तो क्या वह संस्करण अब वही संस्करण है जो मैं यहाँ 4 Co2 मापने वाले नोड्स पर चला रहा हूँ?

लगभग एक जैसा।
कम से कम सीरियल पोर्ट और आपके प्लगइन के लिए कोड समान है।

फिर मैं इसे वैसे ही छोड़ देता हूं और "विशेष" के साथ परीक्षण जारी रखता हूं

मुझे यह स्पष्ट नहीं था कि रिलीज़ में क्या शामिल था और क्या नहीं, कुछ संख्याएँ मेल खाती थीं।

हां, कल जिस बड़े पीआर का मैंने विलय किया था, वह पिछले हफ्तों में मेरे द्वारा किए गए सभी परीक्षण बिल्ड का स्रोत था।

Esp08 14:17 पर जमे हुए, काउंटर चेकसम (पास/असफल): | 3292/70, syslog आगे के विश्लेषण के लिए अलग रखा गया

और क्या नोड का एक साधारण रीबूट (या सेटिंग्स सहेजें) सेंसर को पुनरारंभ करता है (पावर डाउन नहीं)?

कोशिश करेंगे कि अगली बार, काउंटरों की जाँच के बाद ही इसे पावर साइकिल करें।

Esp08 फिर से जमे हुए, काउंटर चेकसम (पास/असफल): | 2660/55

co2-डिवाइस मापदंडों को बचाने से फ्रीज का समाधान हो गया!

Esp08 18:18 फिर से जमे हुए, काउंटर चेकसम (पास/असफल): | 2660/55

co2-डिवाइस मापदंडों को बचाने से फ्रीज का समाधान हो गया!

ठीक है, इसलिए रीसेट करना संभव है।
मैं एन अज्ञात प्रतिक्रियाओं के लिए एक चेक जोड़ूंगा और फिर एक इनिट फिर से करूंगा।

जिससे यह समस्या पूरी तरह से खत्म हो सकती है।

अभी के लिए उन सभी पर होने वाली संपूर्ण धारावाहिक समस्या अब मॉडलए पर और तीन मेगाहर्ट्ज19बी मॉडल सेंसर में से दो के साथ चली गई है।
Esp08, जो एक मॉडल बी है, केवल एक ही है जिसे मैंने एक चर के साथ देखा है "अज्ञात प्रतिक्रिया (हर बार एक बदलते) हेक्स मान" अभी भी लॉगफाइल में है, अगर यह सेंसर खराब व्यवहार करते समय प्लगइन से रीसेट किया जा सकता है, यह समाधान हो सकता है।

सभी को अभी मेगा 201902026 4Mb में अपग्रेड कर रहा है।

पहली बात जो मैंने देखी, Co2 सेंसर प्रकार mhz19B फ्लैश नई छवि के लगभग तुरंत बाद सही मान दे रहा है, पहले भी बहुत तेजी से।

यह वास्तव में आशाजनक लगता है! मैं इस धागे को देख रहा था, एक पल के लिए प्रतीक्षा कर रहा था कि मैं अंत में अपग्रेड कर सकूं। : ग्रिन: मेरे पास एक नोड है जिसमें MH-Z19 और PMS7003 दोनों संलग्न हैं। MH-Z19 90% समय से काम कर रहा है लेकिन कभी-कभी मुझे उसके लिए ESP को रीसेट करना पड़ता है।

हालांकि PMS7003 बहुत अधिक विफल होता दिख रहा है। ज्यादातर बार रीसेट भी मदद नहीं करता है, लेकिन कुछ सेकंड के लिए बिजली काट देने से यह ठीक हो सकता है। मुझे संदेह है कि इसका कनेक्टर अपराधी हो सकता है लेकिन इसे डिबग करने में नहीं आया है। यह धागा मुझे उत्सुक करता है अगर यह अभी भी फर्मवेयर से संबंधित हो सकता है ... मैं इसे एक शॉट देने जा रहा हूं जब मैं सुनिश्चित हो सकता हूं कि यह MH-Z19 के साथ समस्या नहीं पैदा करेगा क्योंकि इसका डेटा अधिक महत्वपूर्ण है।

और हां, मैंने देखा कि #2349 ने केवल MH-Z19 कोड को छुआ है, लेकिन मैं जो बिल्ड चला रहा हूं वह "20100 - मेगा (कोर 2_4_0)" है, जो मुझे लगता है कि काफी पुराना है।

मैं कहना चाहता हूं कि किसी मुद्दे के दोनों पक्षों से इस तरह की दृढ़ता देखना दुर्लभ है। मुझे लगता है कि कई लोगों ने कुछ दिनों के बाद हार मान ली होगी। इस दर्शक @ TD-er और @pwassink की ओर से आपको सलाम!

आप अपग्रेड करने से पहले 1 दिन और प्रतीक्षा करना चाह सकते हैं।
मैं अब नेटवर्क कनेक्टिविटी के लिए कुछ पैच पर काम कर रहा हूं।

जानकारी के लिए धन्यवाद! मैं वैसे भी एक पल के लिए @pwassink रिपोर्ट की प्रतीक्षा करने की योजना बना रहा था (मुझे आलसी)।

बस इतना जान लें कि आपके वर्तमान निर्माण के बाद से बहुत कुछ बदल गया है, और दुख की बात है कि सभी सकारात्मक नहीं हैं।
जिन मुद्दों से हम अभी भी निपटने का प्रयास कर रहे हैं उनमें से एक हार्डवेयर वॉचडॉग रीबूट है। इसलिए हो सकता है कि आप अपने पास मौजूद मौजूदा सेटिंग्स का बैकअप रखना चाहें और अपने द्वारा उपयोग किए जा रहे वर्तमान संस्करण को लिख लें। बस तसल्ली के लिए।
मैं आज के सुधारों द्वारा इन रिबूट में थोड़ा सुधार करने की आशा करता हूं, लेकिन चूंकि इन रिबूट के कई अलग-अलग कारण हैं, मुझे नहीं लगता कि आज के सुधार उन सभी को संभाल लेंगे।

नोट लिया। मैं केवल ESPEasy जैसी प्रणाली में प्रतिगमन से बचने में कठिनाई की कल्पना कर सकता हूं। अपग्रेड करने के बाद मैं किसी भी प्रतिगमन की रिपोर्ट करूँगा (पाठ्यक्रम के अलग-अलग मुद्दों के रूप में)।

मैं यहां मौजूद दो ईएसपी को अपग्रेड करने की योजना बना रहा हूं। केवल उन्हीं के आधार पर मैं देख सकता हूं कि क्या MH-Z19, PMSx003, BMx280, TSL2561, DHT22 सेंसर या OLED SSD1306 डिस्प्ले हैंडलिंग पर रिग्रेशन है। अन्य ईएसपी पर TSL2561 डेटा को बेतरतीब ढंग से वापस करना बंद कर देता है (हालांकि काफी दुर्लभ)। यह बिल्ड "20102 - मेगा" चल रहा है।

यह निर्माण नहीं है, लेकिन आंतरिक फ़ाइल प्रारूप (भ्रमित करने वाला मुझे पता है) आपको sysinfo पृष्ठ में बिल्ड नाम/तिथि मिल सकती है।

यह कम से कम "बिल्ड" फ़ील्ड पर है। बाइनरी फ़ाइल नाम "यहIsTheDummyPlaceHolderForTheBinaryFilename64ByteLongFilenames" है। मैंने शायद इसे सीधे PlatformIO से फ्लैश किया। मुझे उसी संस्करण को चमकाने में कुछ कठिनाई हो सकती है, जैसा कि लगभग एक साल पहले था। मैंने टैग का उल्लेख न करने के लिए वास्तव में कोई नोट नहीं बनाया। :जॉय: ठीक है, मुझे लगता है कि अगर मैं पर्याप्त साहसी महसूस नहीं करता तो मैं फर्मवेयर का बैकअप ले सकता हूं।

Sysinfo पेज में कोई बिल्ड टाइमस्टैम्प नहीं है?

एक टाइमस्टैम्प है लेकिन यह ज्यादा मदद नहीं करेगा क्योंकि मुझे याद नहीं है कि मैंने ऐसा करने से पहले नवीनतम कोड खींचा था या नहीं। लेकिन निश्चित रूप से यह कुछ बॉलपार्क देता है।

यह ESP नहीं है जो MH-Z19 और PMS7003 को होस्ट करता है।

लेकिन मुझे लगता है कि यह विषय से बहुत दूर जा रहा है। अस्थायी रूप से थ्रेड को हाईजैक करने के लिए क्षमा करें और किसी भी तरह मेरी टिप्पणियों का उत्तर देने के लिए धन्यवाद!

यह किस संस्करण में तय किया गया था?

कुछ घंटों के बाद मुझे MHZ19 मिलता है: अज्ञात प्रतिक्रिया: 0 0 0 0 0 0 0 0 0
रीबूट ठीक नहीं करेगा इसे अनप्लग करना होगा और इसे वापस प्लग इन करना होगा

मैं एक Wemos 1d मिनी Pro का उपयोग कर रहा हूं, क्या इस संस्करण में इसमें सुधार है?

बिल्ड:⋄ | 20104 - मेगा
-- | --
सिस्टम पुस्तकालय:⋄ | ESP82xx Core 2_5_2, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.1.2 PUYA सपोर्ट
गिट बिल्ड:⋄ | मेगा-20191003
प्लगइन्स:⋄ | 46 [सामान्य]
Md5 बनाएँ: | 3180a4d3e118166b3414444513a6169
एमडी5 चेक: | बीतने के।
निर्माण समय:⋄ | अक्टूबर 3 2019 02:15:29
बाइनरी फ़ाइल नाम:⋄ | ESP_Easy_mega-20191003_normal_ESP8266_4M1M.bin

धन्यवाद

हाँ और पिछले संस्करण भी।
मैं 20190928 बिल्ड के साथ प्रयास करने का सुझाव दूंगा, क्योंकि अक्टूबर में कुछ अन्य मुद्दे थे (जिसे मैं पिछले सप्ताह या तो ठीक कर रहा हूं)

कुछ घंटों तक चलने के बाद, आप प्लगइन पृष्ठ पर दिखाई गई पठन त्रुटियों की संख्या पर भी एक नज़र डालना चाह सकते हैं।

उदाहरण के लिए मेरी अपनी इकाइयों में से एक (3 दिन अपटाइम)

NB फ़िल्टर (स्क्रीनशॉट में "यूज़ अनस्टेबल" पर सेट) का MH-Z19B सेंसर पर कोई अर्थ नहीं है, यह केवल -A संस्करण के लिए लागू है।

और दूसरा:

जैसा कि आप देख सकते हैं, असफल पढ़ने की संख्या न्यूनतम है।
यदि आपमें कुछ त्रुटियाँ हैं, तो आपके सामने एक और समस्या आ सकती है।

वे 11 रीसेट जहां मैं इसे फिर से प्लग-इन किए बिना फिर से बूट करने की कोशिश कर रहा हूं, मुझे कोई त्रुटि दिखाई नहीं दे रही है, लेकिन मैं इसे एक और शॉट दे सकता हूं, क्या मुझे सॉफ्टवेयर सीरियल का उपयोग करना चाहिए?

हार्डवेयर सीरियल बेहतर है, लेकिन फिर आपको टूल्स-> एडवांस-> सीरियल पोर्ट में सीरियल पोर्ट को भी डिसेबल करना होगा। (जैसा कि आपके स्क्रीनशॉट में बताया गया है :))

मुझे यकीन नहीं है कि बोर्ड पर मौजूद यूएसबी से सीरियल एडॉप्टर का संचार पर प्रभाव पड़ सकता है।
जब संदेह हो तो आप सॉफ्टवेयर सीरियल में बदल सकते हैं।

बिल्ड: ESP_Easy_mega_20201130_normal_ESP8266_4M1M
एफएचईएम को रिपोर्ट करना।
मुझे भी इसी तरह की समस्या थी: MH-Z190B सेंसर हर कुछ घंटों में जम जाता है और जब मैं हार्डवेयर सीरियल का उपयोग करता हूं तो 400 तक गिर जाता है।
सॉफ्टवेयर सीरियल में स्विच करने के बाद यह सामान्य रूप से काम करने लगता है और अब जमता नहीं है।
2 स्क्रीनशॉट संलग्न हैं।

I2C के साथ संलग्न BME280 ठीक काम करता है और हर समय रिपोर्टिंग करता रहता है

हम्म यह अजीब है।
यह किस HW सीरियल पोर्ट से जुड़ा था?
बोर्ड से और क्या जुड़ा है? (जैसे USB से सीरियल चिप)
क्या टूल्स-> उन्नत पृष्ठ पर "सीरियल का उपयोग करें" अनियंत्रित है?

यह GPIO-13 (D7) <- TX और GPIO-15 (D8) -> RX (पहले HW में अब SW में) से जुड़ा है क्योंकि मैं USB- पोर्ट (CH340) के माध्यम से संदेशों को पढ़ने के लिए TXD0 और RXD0 का उपयोग करना चाहता था ) Wemos D1 मिनी का।
क्या "सीरियल का उपयोग करें" का अर्थ है "सीरियल सेटिंग्स - सीरियल पोर्ट सक्षम करें:" चेक किया गया? मैंने यूएसबी द्वारा संदेशों को पढ़ने में सक्षम होने के लिए इसे चेक किया है।

ESP8266 पर HW सीरियल सीरियल0 का उपयोग करता है।
यदि आप उसी सीरियल पोर्ट पर लॉग भी भेजते हैं, तो सेंसर क्रैश हो सकता है क्योंकि यह उस पोर्ट के माध्यम से लॉग भेजे जाने पर प्राप्त होने वाले "कमांड" को नहीं समझता है।

यदि आप HW सीरियल पोर्ट से कुछ कनेक्ट करते हैं, तो आपको अब अन्य डेटा नहीं भेजना चाहिए। इस प्रकार आपको टूल्स-> एडवांस्ड पेज पर "यूज सीरियल" को डिसेबल कर देना चाहिए।

कल, मुझे दूसरा सेंसर MH-Z19C मिला। यह सीरियल 2 पर एचडब्ल्यू-सीरियल के साथ ठीक काम करता प्रतीत होता है। चूंकि सेंसर सभी पिन D7 (GPIO 13) और D8 (GPIO 13) (RXD2 और TXD2) से जुड़े थे, इसलिए जहां तक ​​मैं हूं, सीरियल0 (पिन RXD0 (GPIO3) और TXD0 (GPIO1)) के साथ कोई विरोध नहीं होना चाहिए। पिनआउट को समझना मुझे लगता है कि पहला सेंसर (किसी अन्य आपूर्तिकर्ता से MH-Z19B) सिर्फ एक नकली था जो ठीक से काम नहीं कर रहा था, ...
इसलिए सेंसर खरीदते समय सावधान रहें। दूसरा, जो मुझे कल मिला वह विंसन लोगो के साथ एक बेहतर पैकेजिंग में था और एक परीक्षण प्रमाणपत्र शामिल हो गया था। आपूर्तिकर्ता मुझे पहले बेचने वाले की तुलना में अधिक गंभीर लगता है।