Espeasy: MQTT ने 20181008 से काम करना बंद कर दिया

20181004 में निम्नलिखित बदल गया है:

• [sendHttp] #1830 टाइमआउट सेट करें और टाइमआउट पर जल्दी बाहर निकलें
• [वाईफाई क्लाइंट] टाइमआउट सेट करें और इसे नियंत्रकों के लिए कॉन्फ़िगर करने योग्य बनाएं
• [कोर २.४.१] २.४.२ . से कोर २.४.१ पर वापस जाएं

और 20181006 में:

• [वाईफाई] नियंत्रक सेटिंग्स में कनेक्शन के प्रयासों में देरी जोड़ें

क्या आप शायद 20181003 बिल्ड का परीक्षण कर सकते हैं और शायद ये अन्य 2 भी समस्या को कम करने के लिए?

मैं कोशिश करूंगा लेकिन मुझे डर है कि मैं इसे शनिवार तक नहीं कर पाऊंगा। ;-)

क्या आपको पता है कि एमक्यूटीटी कनेक्शन के खो जाने में कितना समय लगता है?
और क्या यह किसी तरह वाईफाई रीकनेक्ट के साथ मेल खाता है?

जहाँ तक मैं देख सकता था, कोई वाईफ़ाई हानि नहीं थी।
कि एमक्यूटीटी कनेक्शन खो गया था आज सुबह काफी तेज था (10 मिनट) लेकिन मेरे पास आईओब्रोकर की अंतिम प्रविष्टि के अनुसार भी घंटे थे ...
मैं आज रात 3 में से कम से कम एक निर्माण शुरू करने की कोशिश करूंगा।

एक चेक के रूप में; क्या आप इसे स्वयं बनाते हैं, या रात्रिकालीन निर्माण का उपयोग करते हैं?

जाँच करने के लिए एक और बात:

क्या आप सुनिश्चित हैं कि MQTT काम करना बंद कर रहा है?
मेरा यहाँ थोड़ी देर बाद "कनेक्शन खो गया" दिखाता है लेकिन सब कुछ अभी भी एमक्यूटीटी के साथ काम कर रहा है।

एकमात्र बग जो मैं देख रहा हूं वह संदेश "कनेक्शन खो गया" है जबकि सब कुछ अभी भी काम कर रहा है।
उदाहरण के लिए मुझे MQTT कंट्रोलर द्वारा अपटाइम मिनट मिलते हैं।
थोड़ी देर के बाद (10 मिनट और 10 घंटे के बीच) मुझे "कनेक्शन खो गया" दिखाई देता है लेकिन मिनट अभी भी एमक्यूटीटी पर भेजे जाते हैं।

ग्रीट्ज़
साशा

MQTT को एक बार फिर से कनेक्ट करना चाहिए जैसे ही उसे पता चलता है कि वह अब कनेक्ट नहीं था।
@Sasch600xt अन्य संबंधित मुद्दे भी देखें:
https://github.com/letscontrolit/ESPEasy/issues/1873#issuecomment -431170001

20180927 से पहले कुछ बिल्ड, जिसे आप ठीक काम करने की रिपोर्ट करते हैं, मैंने एमक्यूटीटी नियंत्रकों के लिए एक फिक्स जोड़ा जिसमें ईएसपी पर एमक्यूटीटी क्लाइंट खुद को एक नया क्लाइंट आईडी देगा, बस ब्रोकर को एक नया कनेक्शन मना करने से रोकने के लिए जब ब्रोकर अभी भी उस क्लाइंट से मौजूदा कनेक्शन मानता है और क्लाइंट को लगता है कि यह डिस्कनेक्ट हो गया है।

क्या आप नियंत्रक की टाइमआउट सेटिंग बढ़ा सकते हैं? डिफ़ॉल्ट 1000 मिसे था, इससे पहले कि मैंने उस सेटिंग को पेश किया और पहले बिल्ड में डिफ़ॉल्ट रूप से 100 मिसे थे। बाद में मैंने डिफ़ॉल्ट (नई सेटिंग्स के लिए) को 300 मिसे में बदल दिया।
तो हो सकता है कि आप इसे केवल एक परीक्षण के रूप में 300 या उच्चतर (1000 मिसे से अधिक नहीं) पर सेट करने का प्रयास कर सकें। (कोई फर्क नहीं पड़ता कि कौन सा संस्करण, कम से कम एक जो विफल हुआ करता था)

मैंने 1 (5 में से) इकाइयों के साथ एक ही समस्या का अनुभव किया। मैंने एमक्यूटीटी नियंत्रक सेटिंग्स के साथ थोड़ा सा खेला है (न्यूनतम भेजें अंतराल, अधिकतम कतार गहराई, अधिकतम पुनर्प्रयास और पूर्ण कतार कार्रवाई); सेटिंग्स जो अब इस इकाई के साथ मेरे लिए काम करती हैं: 1000ms, 5/5 और "सबसे पुराना हटाएं"।

ठीक खबर...
ऐसा लगता है कि यह वही मुद्दा है जैसा कि 12 घंटे पहले blb4github ने टिप्पणी की थी, के बारे में बात कर रहा है। एक नई इकाई ली और यह अब तक बिना किसी समस्या के काम करता है !!!! ऐसा लगता है कि "पुराने" को स्मृति समस्या या समय की समस्या है। मैं इसमें टाइमआउट बढ़ाने की कोशिश करूंगा ... आपको सूचित करते रहें ;-)
बीटीडब्ल्यू .. (क्षमा करें .. एटम के साथ सेल्फबिल्ड .. क्योंकि मुझे सभी प्लगइन्स नहीं चाहिए ... लेकिन अब तक यह हमेशा अच्छा रहा ..) आप सभी इस पर बहुत अच्छा काम कर रहे हैं ... और जहां तक ​​​​मुझे पता चला है यह केवल यही है (और इसलिए नवीनतम एसडब्ल्यू वाला एक) जिसमें यह समस्या है। मैं सेटिंग्स बढ़ाऊंगा और आपको बता दूंगा।

सादर पीटर

@fraeggle क्या आपके लिए अच्छे और बुरे मॉड्यूल सिस्टमइन्फो पेजों के स्क्रीनशॉट को यहां पेस्ट करना संभव है? (esp और भंडारण अनुभाग)

और हार्डवेयर का कुछ विवरण।
उदाहरण के लिए, मुझे लगता है कि हाल ही में सोनऑफ़ मॉड्यूल में कुछ बदलाव हुए हैं।
Sonoff बेसिक और S20

@fraeggle क्या आप शायद समस्याग्रस्त नोड का पूरा वाइप भी कर सकते हैं और साफ करना शुरू कर सकते हैं?
खाली बिन फ़ाइलें रिलीज़ ज़िप फ़ाइलों में शामिल हैं।

हाय टीडी-एर
मैंने पहले खराब नोड को मिटा दिया था ... चूंकि मैंने टाइमआउट सेटिंग्स को 800ms . में बदल दिया है
यह स्थिर है। वोल्टेज हर 120 सेकंड में अपडेट किया जा रहा है।

हार्डवेयर कुछ खास नहीं.... क्योंकि अभी भी INA219 के आने का इंतजार है.. ;-)

सादर पीटर

अप मैंने दुर्भाग्य से इसे बंद कर दिया ..

लेकिन मुझे लगता है कि इस "कामकाज" के साथ इसे बंद किया जा सकता है ... मुझे सच में लगता है कि यह अब एक इकाई समस्या है ..
टीडी-एर के बारे में आप क्या सोचते हैं?

फिर भी यह अजीब है कि इकाइयाँ इस पहलू में भिन्न हैं।
यह सुझाव देगा कि एक इकाई में वाईफाई की स्थिरता खराब है

मैं सहमत हूं लेकिन मुझे लगता है कि इस इकाई में सहिष्णुता सीमा बहुत बड़ी है। जैसा कि मैंने आपको बताया, चूंकि मैं 800 एमएस में बदल गया हूं, यह ठीक काम करता है ...
इसलिए यदि आप सहमत हैं तो मैं इसे बंद कर दूंगा, इस तथ्य के कारण कि टाइमआउट बदलने की क्षमता है।

आपकी सहायता के लिए धन्यवाद..

सादर पीटर

मैंने पाया "20181007 के बाद से एमक्यूटीटी ओपन हब "कनेक्शन लॉस्ट" # 1873 दिखाता है।
शायद वही मुद्दा?
टीडी-एर मुझे बताएं कि क्या मैं लॉग या ऐसा कुछ बनाकर मदद कर सकता हूं ...
ओपनहैब (आईओब्रोकर के साथ) का उपयोग करना। लेकिन अब तक टाइमआउट को 800ms . पर सेट करने के बाद कोई त्रुटि नहीं हुई है

क्या आपके द्वारा चलाए जा रहे OpenHAB के लिए MQTT ब्रोकर आपके अपने नेटवर्क में कंप्यूटर पर स्थापित है, या बाहरी है?
और यदि स्थानीय है, तो क्या यह शायद ऐसे कंप्यूटर पर स्थापित है जिसमें संसाधनों की कमी है?

मेरे पास २०१८१०२० पर ३९४ मिनट के बाद से एक परीक्षण भी चल रहा है।
800ms पर टाइमआउट।
कभी-कभी यह 24 घंटे या उससे भी अधिक समय के बाद डिस्कनेक्टेड के रूप में दिखाई देता है। लेकिन मैं 2 दिन तक नहीं पहुंचा।
और फिर, "कनेक्शन लॉस्ट" दिखाने के बाद भी मेरे लिए सभी काम कर रहे हैं। तो यह सिर्फ वही संदेश है जो मेरे लिए भ्रमित करने वाला है। मैं आपको सूचित करता रहूँगा

कनेक्शन खो गया केवल एक सूचना संदेश है जो दर्शाता है ... कनेक्शन खो गया था।
लेकिन इसे एक नया कनेक्शन पुनरारंभ करना चाहिए।
Sysinfo पेज में आप देख सकते हैं कि कितनी बार वाईफाई कनेक्शन खो गया था और फिर से बनाया गया था और यह भी कि आखिरी (पुनः) एक्सेसपॉइंट से कनेक्ट होने के बाद से यह कितने समय तक वाईफाई से जुड़ा है।

जैसे ही वाईफाई कनेक्शन बाधित होता है, यह भी मान लेगा कि एमक्यूटीटी कनेक्शन को फिर से बनाया जाना है, इसलिए यह एमक्यूटीटी ब्रोकर के कनेक्शन को खो जाने पर विचार करेगा।
4 सप्ताह पहले तक, यह संभव था कि MQTT ब्रोकर नए कनेक्शन के प्रयास को स्वीकार नहीं करेगा, क्योंकि ब्रोकर अभी भी क्लाइंट को जुड़ा हुआ मानता था।
इसके परिणामस्वरूप अनिश्चितकालीन पुन: कनेक्ट करने का प्रयास हो सकता है, जब क्लाइंट कनेक्ट करने का प्रयास करता रहा और ब्रोकर कनेक्शन को स्वीकार नहीं करता।
मैंने प्रत्येक पुन: कनेक्ट होने पर MQTT क्लाइंट आईडी को बदल दिया (क्लाइंट आईडी में पुन: कनेक्ट की संख्या जोड़कर) ताकि ब्रोकर इसे एक नया ग्राहक मान सके।
इसका परिणाम एक त्वरित पुन: कनेक्ट होता है, केवल दोष के साथ, ब्रोकर एलडब्ल्यूटी (अंतिम वसीयत और वसीयतनामा) भेज देगा क्योंकि यह मानता है कि ग्राहक डिस्कनेक्ट हो गया है।

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

संक्षेप में, ऐसे कई विकल्प हैं जिन पर ब्रोकर से कनेक्शन खो सकता है और मुझे यकीन नहीं है कि आपके मामले में यह क्यों खो गया है।
टाइमआउट, वाईफाई डिस्कनेक्ट, ब्रोकर की कुछ अज्ञात प्रतिक्रिया या कोई अन्य कारण हो सकता है।

ठीक मिल गया।
बहुत अच्छा बयान, धन्यवाद।
मैं अभी मिनट ५०७ पर हूं / एचएबी नियंत्रक / ८००ms टाइमआउट खोलें।
अब तक सब अच्छा है :)

क्या मुझे नियंत्रक के नए उदाहरणों के लिए डिफ़ॉल्ट टाइमआउट को वापस 1000 मिसे पर सेट करना चाहिए?

अच्छी तरह से ...... 36 और घंटे दे दो ..... तो मुझे पता है कि बग 800ms के साथ भी आ रहा है या नहीं।

मिनट ६२९ अब बिना किसी समस्या के...

अजीब... 800ms में परिवर्तन के बाद निम्नलिखित खोजे गए।
अंतिम डिस्कनेक्ट कारण | (200) बीकन टाइमआउट
नंबर फिर से जुड़ता है | 3
दास बीकन टाइमआउट का क्या मतलब है?
MQTT अभी भी चल रहा है लेकिन अभी Sasch600txt जैसा ही है। लेकिन पहले से अलग... MQTT अभी भी काम कर रहा है
केवल ब्रोकर ही बताता है कि यह जुड़ा नहीं है।

बीकन फ्रेम के बारे में अधिक जानकारी के लिए, विकिपीडिया देखें
संक्षेप में, एक्सेस प्वाइंट समय-समय पर एक पैकेट भेजता है जिसमें नेटवर्क के बारे में जानकारी होती है।
यह अंतराल आमतौर पर 100 टीयू (102.4 मिसे) होता है।
ईएसपी मॉड्यूल हर बार इस बीकन को सुनने की कोशिश कर रहा है, लेकिन कई कारणों से यह बीकन फ्रेम को याद कर सकता है। टाइमआउट 100 टीयू से अधिक लंबा है, इसलिए बीकन टाइमआउट की रिपोर्ट करने के लिए इसे इन बीकन फ़्रेमों में से कई को याद करना चाहिए।
ऐसे बीकन फ्रेम के छूटने के कारण हैं:

• अन्य अवरुद्ध कार्यों को संसाधित करने में बहुत व्यस्त (बहुत संभावना है)
• पहुंच बिंदु दूसरों की उच्च यातायात मांगों के कारण एक बीकन नहीं भेज रहा है (ब्रांड/मॉडल/सेटिंग्स के आधार पर)
• आरएफ गड़बड़ी (यह संभावना नहीं है कि यह कितनी बार होता है)
• घड़ी बहाव (वास्तव में संभावना नहीं)

तो "बीकन टाइमआउट" ईएसपी नोड्स पर हर समय हो रहा है।
मैं प्रत्येक प्लगइन/नियंत्रक को कम समय के स्लाइस का उपयोग करने के लिए कड़ी मेहनत कर रहा हूं ताकि कार्यों को जितना संभव हो उतना कम अवरुद्ध कर सकें।

मैं पुष्टि कर सकता हूं कि सभी फ्रैगल ने कहा।
आज रात किसी समय मुझे "कनेक्शन खो गया"

सप्ताहांत शुभ रहे :)
साशा

@फ्रैगल :
यदि यह "कनेक्शन लॉस्ट" के रूप में दिखाई देता है, तो ESPEasy की नियंत्रक सेटिंग्स में जाने का प्रयास करें, नियंत्रक को सरल अक्षम करें -> सहेजें, इसे फिर से सक्षम करें -> सहेजें। तब कम से कम मेरे लिए यह फिर से जुड़ा हुआ दिखाई देता है। समाधान नहीं, लेकिन कम से कम दिलचस्प :) क्या यह IPSymcon आप उपयोग कर रहे हैं?

@ टीडी-एर:
बहुत व्यस्त कार्य? अच्छी तरह से ... "टेस्ट यूनिट" में मैं यहां चल रहा हूं, मैं हर 60 सेकंड में केवल अपटाइम मिनट भेजता हूं ...... इस इकाई में और कुछ नहीं चल रहा है ..... इसलिए शायद सबसे छोटा संभव सिस्टम

@ Sasch600xt शब्द "बहुत व्यस्त" शायद वास्तविक मुद्दे का वर्णन करने वाला सबसे अच्छा नहीं है।
चीजों को करने का Arduino तरीका है:

• कॉल setup() call
• बार-बार loop() पर कॉल करें।

उसके ऊपर, ESP8266 (और ESP32 Arduino) के लिए Arduino संस्करण Arduino भाग के लिए loop() के बाहर कुछ कार्य चला रहा है।
ये कार्य पृष्ठभूमि प्रक्रियाओं के बारे में हैं, जैसे नेटवर्क कनेक्शन और आने वाले ट्रैफ़िक को संभालना आदि।
पृष्ठभूमि कार्यों को केवल यहां निष्पादित किया जाता है:

• loop() का अंत
• Arduino स्पेस के भीतर से delay() या yield() पर कॉल करते समय।

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

जब आप सीरियल लॉग (डीबग स्तर सक्षम के साथ) देखते हैं तो आपको समय के आंकड़े दिखाई देंगे।
उनमें से कुछ एमएसईसी के कई दसियों कर सकते हैं और इस प्रकार इन 'डिस्कनेक्ट' कारणों के लिए उम्मीदवार हैं।

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

इस मुद्दे के बारे में, जब एक कनेक्शन खो गया है, तो मैं एमक्यूटीटी के डिस्कनेक्ट/रीकनेक्ट को देख सकता हूं।
आप किस ब्रोकर का उपयोग कर रहे हैं? मैं यहां मच्छर का उपयोग कर रहा हूं और यह वर्तमान व्यवहार के साथ ठीक काम कर रहा है।

ठीक है, "बहुत व्यस्त" मेरे बारे में कहना थोड़ा आसान था :)

मैं MQTT ब्रोकर के लिए अपने

ग्रीट्ज़
साशा

हाय साशा .. IObroker का उपयोग करना।
@ टीडी-एर बिल्ड 27092018 पर वापस चला गया। ब्रोकर मुझे बताता है कि अभी भी जुड़ा हुआ है ...
वास्तव में भ्रमित करने वाला .. 14 घंटे के भीतर कोई त्रुटि नहीं (नंबर फिर से जुड़ता है | 0)

मैं अभी अपने कंप्यूटर पर IObroker इंस्टॉल कर रहा हूं, बस यह देखने के लिए कि क्या हो रहा है।

संपादित करें:
45 मिनट बाद और मैं अभी भी IObroker को अपने कंप्यूटर पर चलाने में सक्षम नहीं हूं।
सुनिश्चित नहीं है कि यहां क्या हो रहा है, लेकिन विंडोज इंस्टालर काम नहीं करता है (सर्विस बैट फाइल कहीं नहीं मिलती है) और लिनक्स पर इंस्टॉलेशन खत्म नहीं होता है। यह एक ही npm install को बार-बार करने की कोशिश करता रहता है।
Intel CPU होस्ट पर Ubuntu 18.04 पर परीक्षण किया गया और Windows पर बैश (Ubuntu 18.04)

विंडोज़ के साथ निश्चित नहीं .. मुझे लगता है कि कुछ सॉफ्टवेयर निर्भरताएं हैं। इसे रास्पबेरी पर चला रहा है।
विंडोज के लिए ioBroker verwendet Node.js als Plattform und setzt diese vorauus. (डाउनलोड करें: http://nodejs.org/download/) पहले नोड.जेएस को इंस्टॉल करना होगा।

मेरे पास 4 DS18B20 सेंसर से जुड़े एक मॉड्यूल के साथ एक समस्या भी है।
मैंने सोचा था कि यह मेरी रास्पी थी लेकिन एक साफ रास्पियन स्ट्रेथ छवि ली और उस पर मच्छर और नोड-लाल स्थापित किया। वही समस्या, 6-12 घंटे के बाद कनेक्शन टूट जाता है।

डैशबोर्ड: https://emoncms.org/Edegem/scrtmp2e
ESP के 4 वक्र हैं CV_aanvoer, CV_retour और Sanitair_warm, Sanitair_koud

@fluppie यदि आप आधिकारिक बिल्ड का उपयोग करते हैं?

नहीं, मैं अपने आप को PlatformIO/Atom . के साथ निर्मित करता हूँ
संपादित करें: हा, मैंने अच्छी तरह से नहीं पढ़ा, मैं एक आधिकारिक निर्माण की कोशिश करूंगा।

आइए इसे देखें!

नमस्ते

मेरे पास एक ही समस्या है, मैं HomeAssistant का उपयोग कर रहा हूं लेकिन ESPEasy_mega-20181111 fw के बाद समस्या मुझे ठीक लगती है।

धन्यवाद
टी

2-3 दिनों के बाद भी मेरा कनेक्शन टूट रहा था। मैं इसमें अपडेट करूंगा: ESP_Easy_mega-20181112_normal_ESP8266_4096.bin

चलो देखते हैं!

मेरा कॉन खो गया था। 1-10 घंटे के बाद। मेरे पास ~ 10h30min अपटाइम और सभी (5 पीसी) संबंधित मॉड्यूल जुड़े हुए हैं। :-)

ऐसा लगता है कि यह कोशिश करने लायक होगा ... अभी भी 2709 पर क्योंकि एक स्थिर कनेक्शन की आवश्यकता है। कृपया मुझे सूचित रखें। :-))

आप इसके माध्यम से भी अनुसरण कर सकते हैं: https://emoncms.org/Edegem/scrtmp2e और जांचें कि क्या CV_ और Sanitair_ ग्राफ़ हैं :)।

1 दिन अपटाइम और अभी भी ठीक है। :-)

आप इसके माध्यम से भी अनुसरण कर सकते हैं: https://emoncms.org/Edegem/scrtmp2e और जांचें कि क्या CV_ और Sanitair_ ग्राफ़ हैं :)।

:-D Sanitair_warm लगभग ६० C ? थोड़ा कैम्प फायर? ;-)
मैं फर्म की कोशिश करूँगा .. धन्यवाद ...

मैं नहा रहा था ;-)

1 दिन... अभी भी जुड़ा है :-D
12112018 . का उपयोग करना

~ ३ दिन ३ घंटे के बाद मेरी एक इकाई ने एमक्यूटीटी कनेक्शन खो दिया। :-( (मेगा-20181112 4096 वीसीसी एफडब्ल्यू)

@redskinhu :
बस यह सुनिश्चित करने के लिए, क्या यूनिट के MQTT कनेक्शन खो जाने के बाद भी यह ठीक से काम कर रहा है?
क्योंकि मेरी तरफ, यह केवल "कनेक्शन खो गया" के रूप में दिखाई दे रहा है लेकिन फिर भी सभी एमक्यूटीटी कार्यों के साथ ठीक काम कर रहा है।

ग्रीट्ज़
साशा

दरअसल, हर बार एक खोया हुआ कनेक्शन असामान्य नहीं है।
जब तक मानवीय हस्तक्षेप के बिना कनेक्शन का पुनर्निर्माण किया जा रहा है, तब तक कोई समस्या नहीं है।
वाईफाई कनेक्शन को समय-समय पर रीसेट किया जाएगा और इसे रोकने के लिए आप कुछ नहीं कर सकते।
जैसे ही ऐसा कनेक्शन खो जाता है, यह MQTT क्लाइंट को उसी नोड पर फिर से कनेक्ट करने के लिए सूचित करता है।

यह किसी प्रकार की LWT से संबंधित समस्या दिखती है। MQTT पूरी तरह से डिस्कनेक्ट नहीं है, ESPEasy MQTT संदेश भेजता / प्राप्त करता है, लेकिन LWT का नवीनीकरण नहीं किया जाता है, इसलिए HomeAssistant को LWT कनेक्टेड संदेश नहीं मिला, इसलिए यह दिखाता है कि संबंधित सेंसर/स्विच अनुपलब्ध है। यह मेरा सिद्धांत है...

मेरा अभी भी जुड़ा हुआ है और मेरी पहली पोस्ट के विपरीत एमक्यूटीटी एलडब्ल्यूटी भी मुझे जुड़ा हुआ बताता है। अछा लगता है।

दरअसल, हर बार एक खोया हुआ कनेक्शन असामान्य नहीं है।
जब तक मानवीय हस्तक्षेप के बिना कनेक्शन का पुनर्निर्माण किया जा रहा है, तब तक कोई समस्या नहीं है।
वाईफाई कनेक्शन को समय-समय पर रीसेट किया जाएगा और इसे रोकने के लिए आप कुछ नहीं कर सकते।
जैसे ही ऐसा कनेक्शन खो जाता है, यह MQTT क्लाइंट को उसी नोड पर फिर से कनेक्ट करने के लिए सूचित करता है।

ठीक है क्या इस मामले में जुड़े एलडब्ल्यूटी को नवीनीकृत करने की कोई संभावना है?

यह उस समय एलडब्ल्यूटी भेजने वाला है जब यह कनेक्शन को नवीनीकृत करता है।

मेरे पास अभी एक नोड है जिसे एलडब्ल्यूटी में डिस्कनेक्ट किया गया दिखाया गया है और यह माप को ठीक भेजता है। थोड़ा पुराना निर्माण... शायद यह आपको कुछ बताए

जीआईटी संस्करण: | मेगा-20181008
अपटाइम: | 3 दिन 17 घंटे 36 मिनट

मैंने अजीब चीजें देखी हैं जब ईएसपी नोड को लगता है कि यह डिस्कनेक्ट हो गया था और उसे फिर से जोड़ने की जरूरत है, लेकिन ब्रोकर असहमत है।

नमस्ते

मैंने एक छोटी सी जांच की। ऐसा लगता है कि एलडब्ल्यूटी ही समस्या है। मेरे एक ESP ने इस MQTT को "डिस्कनेक्टेड" चीज़ को फिर से बनाया।

सब कुछ ठीक काम कर रहा है, सेंसर/स्विच। लेकिन गृह सहायक उन्हें नहीं देख सका क्योंकि कॉन्फ़िगरेशन में मैंने एलडब्ल्यूटी विवरण प्रदान किया था।

- platform: mqtt
  name: "Socket 02"
  command_topic: "home/Socket02_ESP12F/GPIO/13"
  state_topic: "home/Socket02_ESP12F/Relay/State"
  availability_topic: "home/Socket02_ESP12F/status/LWT"
  payload_available: "Connected"
  payload_not_available: "Connection Lost"
  payload_on: "1"
  payload_off: "0"
  qos: 1

मैंने MQTT ट्रैफ़िक की जाँच की: मुझे सेंसर डेटा मिला और मैं GPIO को चालू/बंद कर सकता था। सब कुछ ठीक है उदा। एलडब्ल्यूटी।

और जब मैंने एक LWT "कनेक्टेड" संदेश प्रकाशित किया और सब कुछ सामान्य हो गया।

मुझे उम्मीद है यह मदद करेगा।

टी

पुनश्च:
मैं एक नियम के बारे में सोच रहा हूं जो एलडब्ल्यूटी कनेक्टेड संदेश प्रकाशित कर सकता है यदि एलडब्ल्यूटी संदेश डिस्कनेक्ट हो गया है, लेकिन दुख की बात है कि मैं एमक्यूटीटी स्ट्रिंग आयात नहीं कर सकता ;-)

वैसे भी मैं नई fw रिलीज का बेसब्री से इंतजार कर रहा हूं। 4 लंबे दिन ....

मैं सोमवार/मंगलवार को दूर गया हूं और बाद के दिन वास्तव में व्यस्त थे;)

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

MQTT ब्रोकर की टाइमआउट सेटिंग क्या है?
मैं इस संभावना के बारे में सोच रहा हूं कि ब्रोकर एक खोए हुए कनेक्शन को मानता है, लेकिन ईएसपी नोड अभी भी कार्य करता है जैसे यह सक्रिय है और अभी भी जुड़ा हुआ है।

मैंने 100-1000 एमएस की कोशिश की। अब 300. कोई बात नहीं।

नियंत्रक में नहीं, दलाल में।
वे समय 10 - 15 सेकंड के क्रम में हैं।
तो कृपया ब्रोकर के कॉन्फिग में जांचें कि किस टाइमआउट का उपयोग किया जा रहा है।

मैंने LWT टाइमआउट के बारे में कुछ भी नहीं बदला और मुझे अपने Mosquitto config में कोई प्रासंगिक सेटिंग नहीं मिली। इसे डिफ़ॉल्ट होना चाहिए। मुझे दस्तावेज़ों में भी कोई एलडब्ल्यूटी टाइमआउट सेटिंग नहीं मिली।

नहीं LWT टाइमआउट नहीं, ब्रोकर का टाइमआउट।
यदि कोई क्लाइंट टाइमआउट अवधि में कोई संदेश नहीं भेजता है, तो ब्रोकर उसे डिस्कनेक्ट करने पर विचार करेगा।
इसलिए यदि क्लाइंट किसी अन्य टाइमआउट सेटिंग का उपयोग करता है, तो यह हो सकता है कि ब्रोकर क्लाइंट को डिस्कनेक्ट मानता है और क्लाइंट फिर से कनेक्ट करने का प्रयास नहीं करता है।

मैं mqtt विनिर्देशन से जो समझता हूं वह ब्रोकर एलडब्ल्यूटी भेजता है जब क्लाइंट से कीप अलाइव अवधि के भीतर क्लाइंट से कोई संदेश प्राप्त नहीं होता है जो क्लाइंट द्वारा निर्धारित किया जाता है। ब्रोकर पक्ष में कॉन्फ़िगर करने के लिए कुछ भी नहीं है।

देखें https://www.hivemq.com/blog/mqtt- Essentials-part-10-alive-client-take-over

तथा

https://www.hivemq.com/blog/mqtt- Essentials-part-9-last-will-and-testament

यह सच है, लेकिन मैं जो जानना चाहता हूं वह यह है कि दलाल पक्ष पर यह "जीवित अवधि रखें" क्या है।
मुझे पता है कि यह ESPeasy की तरफ तय है।
लेकिन अगर ये एक-दूसरे के साथ तालमेल नहीं बिठाते हैं, तो आप अजीब चीजें होते हुए देखेंगे।

एचएम मेरे पास ऐसा कुछ सेट करने की कोई संभावना नहीं है

लेकिन फिर भी कहते हैं "जुड़ा हुआ"। 4 दिन :-D

बस एक मेगा-20181006 ने ऐसा ही किया। LWT को ऑनलाइन अपडेट नहीं किया गया लेकिन सामान्य रूप से MQTT काम कर रहा है

@ jimmys01 क्या आप अपने ब्रोकर में देख सकते हैं कि क्या यह क्लाइंट आईडी के आधार पर निर्णय ले रहा है? (कनेक्शन खो जाने पर यह बदल जाता है)
क्लाइंट आईडी का यह परिवर्तन कुछ ऐसा है जिसे मैंने सितंबर के अंत में जोड़ा था।

@ टीडी-एर, मुझे इसे पुन: पेश करने का एक तरीका मिला! मैं माइक्रोटिक राउटर से वेमोस को डी-ऑथेंट करता हूं और यह सीधे बैक अप से जुड़ता है, लेकिन एलडब्ल्यूटी ऑफ़लाइन रहता है जबकि एमक्यूटी अभी भी काम कर रहा है। मुझे वसीयत में परीक्षण करने के लिए बिल्ड भेजें

क्या आप MQTT ब्रोकर में क्लाइंट आईडी भी देख सकते हैं?
यदि क्लाइंट आईडी के पीछे "-1" या कुछ है, तो इसका मतलब है कि यह नई क्लाइंट आईडी स्वीकार करता है।
यदि नहीं, तो इसका कुछ समय पहले मेरे द्वारा बनाए गए क्लाइंट आईडी के परिवर्तन से कुछ लेना-देना हो सकता है।

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

मेरे द्वारा esp और ब्रोकर दोनों को पुनः आरंभ करने के बाद नया कनेक्शन

 New connection from 10.10.1.53 on port 1883.
1542965214: New client connected from 10.10.1.53 as aquariums_1 (c1, k10, u'openhabian').

क्लाइंट को डी-ऑथर्ड करें और क्लाइंट फिर से कनेक्ट हो जाता है। ब्रोकर ने इस बार क्लाइंट LWT को किसी कारण से ऑनलाइन छोड़ दिया...

1542965214: New client connected from 10.10.1.53 as aquariums_1 (c1, k10, u'openhabian').
1542965308: New connection from 10.10.1.53 on port 1883.

दूसरा डी-ऑथ

1542965308: New client connected from 10.10.1.53 as aquariums_1_1 (c1, k10, u'openhabian').
1542965308: Socket error on client aquariums_1, disconnecting.
1542965385: New connection from 10.10.1.53 on port 1883.

इस रीकनेक्ट से और एलडब्ल्यूटी के ऑनलाइन बने रहने पर, एमक्यूटीटी संदेश ठीक काम करते हैं। ग्राहक के नाम पर अतिरिक्त _1_1 पर ध्यान दें।

1542965385: New client connected from 10.10.1.53 as aquariums_1 (c1, k10, u'openhabian').
1542965385: Socket error on client aquariums_1_1, disconnecting.
1542965448: Socket error on client aquariums_1, disconnecting.

ठीक है, तो मैं क्लाइंट आईडी परिवर्तन वापस कर दूंगा।
हो सकता है कि क्लाइंट को कनेक्टेड माना जाए तो रिमोट की जांच करना भी संभव है?
मैंने देखा है कि जब ब्रोकर क्लाइंट को अभी भी जुड़ा हुआ मानता है और क्लाइंट फिर से कनेक्ट करने का प्रयास करता है तो कनेक्शन मना कर देता है।
थोड़े अंतराल में पुन: प्रयास करने से यह स्थिति बनी रहेगी और इस प्रकार क्लाइंट कभी भी दोबारा कनेक्ट नहीं हो पाएगा।

इस पर कोई स्टेटस अपडेट?

नहीं अभी तक नहीं।
लेकिन चूंकि हम स्थिरता के अन्य मुद्दों पर (आखिरकार) कुछ प्रगति कर रहे हैं, मुझे लगता है कि यह मेरी सूची में अगला होगा।
पिंग के लिए धन्यवाद;)

मैंने फिर से कनेक्ट होने पर क्लाइंट आईडी बदलने के लिए इसे वैकल्पिक बना दिया। (टूल्स => उन्नत, अन्य MQTT सेटिंग्स के बगल में)

कृपया इस मुद्दे को बंद करें यदि यह अभी काम कर रहा है।
मैं इसे ठीक कर दूंगा।

फिर भी क्लाइंट आईडी क्यों बदलें?

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

ठीक है, इसने इसे हल किया, लेकिन समाधान दूसरों के लिए स्वयं व्याख्यात्मक नहीं है जो उस चेक बॉक्स को देखते हैं।
हो सकता है कि एक पॉप अप जोड़ें जो वाईफाई के नुकसान के बाद पुन: कनेक्शन के मुद्दे होने पर इसे टिक करने के लिए समझाएगा
tasmota मुद्दों पर एक खोज आपको दिखाएगा कि उनके समान दिखने वाले मुद्दे थे, MQTT रिटेन से संबंधित, ऐसा लग रहा था कि यह एक ब्रोकर मुद्दा था।
मेरे पास एक क्लाइंट भी था जो वाईफाई को फिर से कनेक्ट नहीं कर रहा था, जब मैंने इसे डी-ऑथर्ड किया था ... इसकी जांच करने की जरूरत है।

हम इसे दस्तावेज़ीकरण में जोड़ देंगे।
हम दस्तावेज़ीकरण को अप-टू-डेट बनाने के लिए बहुत मेहनत कर रहे हैं और साथ ही बहुत सारे दस्तावेज़ों को विकी से ReadTheDocs में स्थानांतरित कर रहे हैं। इससे प्रति संस्करण दस्तावेज़ीकरण संभव हो जाता है।
दस्तावेज़ फ़ाइलें भी GitHub रिपॉजिटरी में शामिल हैं।

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

नमस्ते

मैंने हाल ही में 20190110 रिलीज़ को स्थापित किया है। यह आशाजनक लग रहा है। 5 दिनों के परीक्षण के बाद कोई LWT समस्या नहीं है। :-)
मेरे पास "एमक्यूटीटी चेंज क्लाइंटआईड एट रीकनेक्ट" विकल्प के साथ कुछ नोड्स हैं और कुछ अक्षम हैं।

खुशखबरी!

टी