Espeasy: توقف MQTT عن العمل منذ 20181008

في 20181004 تغير ما يلي:

• [sendHttp] # 1830 تعيين المهلة والوصول المبكر للخروج عند انتهاء المهلة
• [WiFiClient] اضبط المهلة واجعلها قابلة للتهيئة لوحدات التحكم
• [Core 2.4.1] العودة إلى النواة 2.4.1 من 2.4.2

وفي 20181006:

• [WiFi] أضف تأخيرًا لمحاولات الاتصال في ControllerSettings

هل يمكنك ربما اختبار بناء 20181003 وربما هذين الأخريين أيضًا لتضييق نطاق المشكلة؟

سأحاول لكنني أخشى ألا أتمكن من القيام بذلك حتى يوم السبت. ؛-)

هل لديك أي فكرة عن المدة التي تستغرقها قبل فقدان اتصال MQTT؟
وهل يتزامن بطريقة ما مع إعادة الاتصال بشبكة wifi؟

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

فقط كشيك هل تبنيها بنفسك ، أو تستخدم البنى الليلية؟

شيء آخر للتحقق:

هل أنت متأكد من توقف MQTT عن العمل؟
يظهر بلدي واحد هنا بعد فترة "فقدان الاتصال" ولكن كل شيء لا يزال يعمل مع MQTT.

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

غريتز
ساشا

يجب أن يقوم MQTT بإعادة الاتصال بمجرد أن يكتشف أنه لم يعد متصلًا.
راجع أيضًا @ Sasch600xt مشكلة أخرى ذات صلة:
https://github.com/letscontrolit/ESPEasy/issues/1873#issuecomment -431170001

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

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

لقد واجهت نفس المشكلة مع 1 (من 5) وحدات. لقد لعبت قليلاً مع إعدادات تحكم MQTT (الحد الأدنى للفاصل الزمني للإرسال ، وعمق قائمة الانتظار القصوى ، وإعادة المحاولة القصوى ، وإجراء قائمة الانتظار الكاملة) ؛ الإعدادات التي تعمل الآن بالنسبة لي مع هذه الوحدة: 1000 مللي ثانية ، 5/5 و "حذف الأقدم".

طيب اخبار ...
يبدو أنها نفس المشكلة التي تحدث عنها blb4github التي علق عليها قبل 12 ساعة. استلمت وحدة جديدة وهي تعمل حتى الآن بدون مشاكل !!!! يبدو أن الشخص "القديم" يعاني من مشكلة في الذاكرة أو مشاكل في التوقيت. سأحاول زيادة المهلة في هذا ... إبقائك على اطلاع ؛-)
راجع للشغل .. (آسف .. البناء الذاتي مع Atom .. لأنني لا أريد كل المكونات الإضافية ... ولكن حتى الآن كان الأمر جيدًا دائمًا ..) أنتم جميعًا تقومون بعمل رائع في هذا ... وبقدر ما اكتشفت هذا فقط (وبالتالي الشخص الذي يحتوي على أحدث SW) هو الذي يعاني من هذه المشكلة. سأزيد الإعدادات وأعلمك بذلك.

تحياتي بطرس

fraeggle هل من الممكن أن تلصق هنا لقطة شاشة لصفحات معلومات نظام الوحدات الجيدة والسيئة؟ (esp وأقسام التخزين)

وبعض وصف العتاد.
على سبيل المثال ، لدي شعور بوجود بعض التغييرات مؤخرًا في وحدات سونوف.
Sonoff الأساسية و S20

fraeggle هل يمكنك أيضًا إجراء مسح كامل للعقدة التي بها مشكلات والبدء في التنظيف؟
يتم تضمين ملفات الحاوية الفارغة في ملفات الإصدار ZIP.

مرحبًا TD-er
لقد قمت بمسح العقدة السيئة من قبل ... منذ أن قمت بتغيير إعدادات المهلة إلى 800 مللي ثانية
إنه مستقر. يتم تحديث الجهد كل 120 ثانية.

لا يوجد شيء مميز في الأجهزة .... لأنه لا يزال ينتظر وصول INA219 .. ؛-)

تحياتي بطرس

يو بي إس أنا أغلقته للأسف ..

لكنني أعتقد أنه مع هذا "workaroud" يمكن إغلاقه ... أعتقد حقًا أنها مشكلة وحدة الآن ..
ما رأيك في ذلك TD-er؟

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

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

شكرا لمساعدتك..

تحياتي بطرس

لقد وجدت "منذ 20181007 تعرض MQTT Open Habs" Connection Lost "# 1873.
ربما نفس المشكلة؟
أخبرني TD-er ما إذا كان بإمكاني المساعدة من خلال إنشاء سجلات أو شيء من هذا القبيل ...
باستخدام Openhab (مع IOBroker). ولكن حتى الآن لا يوجد خطأ بعد ضبط المهلة على 800 مللي ثانية

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

لدي أيضًا اختبار قيد التشغيل منذ 394 دقيقة في 20181020.
المهلة 800 مللي ثانية.
يظهر أحيانًا على أنه غير متصل بعد 24 ساعة أو حتى لفترة أطول. لكني لم أصل إلى يومين.
ومرة أخرى ، لا يزال كل شيء يعمل بعد أن يظهر "Connection Lost". لذا فإن الرسالة هي ما يحيرني. سأوافيك بالتطورات

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

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

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

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

طيب ..... فهمت.
بيان جيد جدا ، شكرا لك.
أنا عند الدقيقة 507 الآن / فتح تحكم HAB / مهلة 800 مللي ثانية.
حتى الآن كل شيء جيد :)

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

حسنًا ...... أعط 36 ساعة أخرى ..... ثم أعرف جيدًا أن الخطأ قادم أيضًا بـ 800 مللي ثانية أم لا.

الدقيقة 629 الآن بدون مشاكل ...

غريب ... اكتشف المتابعة بعد التغيير إلى 800 مللي ثانية.
سبب قطع الاتصال الأخير | (200) مهلة الإشارة التنبيهية
عدد يعيد الاتصال | 3
ماذا تعني مهلة das Beacon؟
لا يزال MQTT قيد التشغيل ولكن الآن هو نفسه مثل Sasch600txt. لكن مختلف عن ذي قبل ... لا يزال MQTT يعمل
الوسيط الوحيد يقول أن هذا الشخص غير متصل.

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

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

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

أستطيع أن أؤكد كل قال فريج.
عندما حصلت الليلة على "فقدان الاتصال"

أتمنى لك عطلة نهاية أسبوع سعيدة :)
ساشا

fraeggle :
إذا ظهر كـ "Connection Lost" ، فحاول الدخول إلى Controllersettings لـ ESPEasy ، قم ببساطة بتعطيل وحدة التحكم -> حفظ ، قم بتمكينها مرة أخرى -> حفظ. ثم على الأقل بالنسبة لي يظهر متصلاً مرة أخرى. ليس حلاً ، ولكن على الأقل مثير للاهتمام :) هل هذا IPSymcon الذي تستخدمه؟

@ TD- إيه:
مهام مزدحمة للغاية؟ حسنًا ...... في "TEST UNIT" لديّ تشغيل هنا ، فأنا أرسل فقط دقيقة وقت التشغيل كل 60 ثانية ...... لا يوجد شيء آخر يعمل في هذه الوحدة ..... لذلك ربما يكون أصغر نظام ممكن

@ Sasch600xt ، ربما لا تكون مصطلحات "مشغول جدًا" هي الأفضل التي تصف المشكلة الحقيقية.
طريقة Arduino للقيام بالأشياء هي:

• اتصل بـ setup()
• اتصل بـ loop() مرارًا وتكرارًا.

علاوة على ذلك ، فإن إصدار Arduino لـ ESP8266 (و ESP32 Arduino) يقوم بتشغيل بعض المهام خارج loop() لجزء Arduino.
تتعلق هذه المهام بالعمليات التي تتم في الخلفية ، مثل التعامل مع اتصال الشبكة وحركة المرور الواردة ، وما إلى ذلك.
يتم تنفيذ مهام الخلفية فقط في:

• نهاية loop()
• عند الاتصال بـ delay() أو yield() من داخل مساحة Arduino.

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

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

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

حول هذه المشكلة ، يمكنني النظر في فصل / إعادة اتصال MQTT عند فقد الاتصال.
ما الوسيط الذي تستخدمه؟ أنا أستخدم Mosquito هنا وهو يعمل بشكل جيد مع السلوك الحالي.

حسنًا ، "مشغول جدًا" كان قولًا سهلاً عني :)

أنا أستخدم برنامج نصي يعمل في بيئة التحكم المنزلي ipsymcon الخاصة بي من أجل وسيط MQTT

غريتز
ساشا

مرحبًا Sascha .. باستخدام IOBroker.
عاد @ TD-er إلى الإصدار 27092018. يخبرني الوسيط بأنه ما زلت متصلًا ...
محير حقًا .. لا توجد أخطاء خلال 14 ساعة (يعيد الرقم الاتصال | 0)

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

يحرر:
بعد 45 دقيقة وما زلت غير قادر على تشغيل IObroker على أجهزة الكمبيوتر الخاصة بي.
لست متأكدًا مما يحدث هنا ، ولكن مثبت Windows لا يعمل (لا يمكن العثور على ملف bat للخدمة في أي مكان) والتثبيت على Linux لا ينتهي. يستمر في محاولة إجراء نفس تثبيت npm مرارًا وتكرارًا.
تم الاختبار على Ubuntu 18.04 على مضيف Intel CPU و Bash على Windows (Ubuntu 18.04)

لست متأكدا مع windows .. أعتقد أن هناك بعض تبعيات البرامج. تشغيله على توت العليق.
لنظام التشغيل Windows ioBroker verwendet Node.js als Plattform und setzt diese voraus. (تنزيل: http://nodejs.org/download/) يجب تثبيت node.js الأول.

لدي أيضًا مشكلة في وحدة واحدة مع توصيل 4 مستشعرات DS18B20.
اعتقدت أنه كان RasPi الخاص بي ، لكنني التقطت صورة Raspbian Streth نظيفة وقمت بتثبيت البعوض والعقدة الحمراء عليها. نفس المشكلة ، ينقطع الاتصال بعد 6-12 ساعة.

لوحة القيادة: https://emoncms.org/Edegem/scrtmp2e
المنحنيات الأربعة من ESP هي 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 ساعات. لدي وقت تشغيل يصل إلى 10 ساعات و 30 دقيقة وجميع الوحدات ذات الصلة (5 قطعة) متصلة. :-)

يبدو أنه سيكون من المفيد المحاولة ... لا يزال على 2709 لأنك بحاجة إلى اتصال مستقر. من فضلك ابقني على اطلاع. :-))

يمكنك أيضًا المتابعة عبر: https://emoncms.org/Edegem/scrtmp2e وتحقق مما إذا كانت الرسوم البيانية CV_ و Sanitair_ موجودة :).

وقت تشغيل ليوم واحد ولا يزال على ما يرام. :-)

يمكنك أيضًا المتابعة عبر: https://emoncms.org/Edegem/scrtmp2e وتحقق مما إذا كانت الرسوم البيانية CV_ و Sanitair_ موجودة :).

:-D Sanitair_warm ما يقرب من 60 درجة مئوية؟ القليل من نار المعسكر؟ ؛-)
سأحاول الشركة .. شكرا ...

كنت أستحم ؛-)

يوم واحد ... لا يزال متصلاً :- D.
باستخدام 12112018

بعد مرور 3 أيام تقريبًا و 3 ساعات ، فقدت إحدى وحدتي اتصال MQTT. :- ((mega-20181112 4096 VCC fw)

redskinhu :
فقط للتأكد ، هل لا يزال يعمل بشكل جيد بعد أن فقدت الوحدة اتصال MQTT؟
لأنه من جانبي ، يظهر فقط على أنه "فقد الاتصال" ولكنه لا يزال يعمل بشكل جيد مع جميع إجراءات MQTT.

غريتز
ساشا

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

يبدو نوعًا من مشكلة متعلقة بـ LWT. لم يتم قطع اتصال MQTT تمامًا ، يرسل ESPEasy / يستقبل رسائل MQTT ولكن لم يتم تجديد LWT ، لذا لم يحصل HomeAssistant على رسالة LWT المتصلة من ثم يظهر أن المستشعر / المفتاح ذي الصلة غير متوفر. هذه نظريتي ...

منجم لا يزال متصلاً وعلى عكس منشوري الأول ، حتى MQTT LWT يخبرني بالاتصال. تبدو جيدا.

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

طيب هل هناك إمكانية لتجديد اتصال LWT في هذه الحالة؟

من المفترض أن يرسل LWT في اللحظة التي يجدد فيها الاتصال.

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

إصدار GIT: | ميجا 20181008
الجهوزية: | 3 أيام 17 ساعة 36 دقيقة

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

أهلا

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

كل شيء يعمل بشكل جيد ، أجهزة الاستشعار / المفاتيح. لكن مساعد Home لم يتمكن من رؤيتهم لأنني قدمت تفاصيل LWT في التكوين.

- 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.

وبعد أن نشرت رسالة LWT "Connected" وعاد كل شيء إلى طبيعته.

اتمني ان يكون مفيدا.

تي

ملاحظة:
أفكر في قاعدة واحدة يمكنها نشر رسالة LWT Connected إذا كانت رسالة LWT غير متصلة ، لكن للأسف لا يمكنني استيراد سلاسل MQTT ؛-)

على أي حال ، كنت أتطلع بفارغ الصبر إلى إصدار مهاجم جديد. 4 أيام طويلة ....

لقد كنت بعيدًا يوم الاثنين / الثلاثاء والأيام التالية كانت مشغولة حقًا ؛)

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

ما هو إعداد المهلة لوسيط MQTT؟
أفكر في احتمال أن يفترض الوسيط فقدان الاتصال ، لكن عقدة ESP لا تزال تعمل كما لو كانت نشطة ولا تزال متصلة.

حاولت 100-1000 مللي ثانية. الآن 300. لا يهم.

ليس في وحدة التحكم في الوسيط.
هذه الأوقات في حدود 10 - 15 ثانية.
لذا يرجى التحقق من تهيئة الوسيط لمعرفة المهلة المستخدمة.

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

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

ما أفهمه من مواصفات mqtt ، يرسل الوسيط LWT عندما لا يتلقى رسالة من العميل خلال فترة Keep Alive التي يحددها العميل. لا شيء لتكوينه من جانب الوسيط.

راجع 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 أيام: - د

كان مجرد واحد ميجا 20181006 يفعل الشيء نفسه. لم يتم تحديث LWT إلى الإنترنت ولكن يعمل بشكل طبيعي MQTT

@ jimmys01 هل يمكنك أن ترى في الوسيط الخاص بك ما إذا كان يعتمد القرار على معرّف العميل؟ (هذا يتغير عند فقد الاتصال)
هذا التغيير في معرف العميل هو شيء أضفته في أواخر سبتمبر.

@ TD-er ، لقد وجدت طريقة لإعادة إنتاج هذا! أقوم بفك مصادقة wemos من جهاز التوجيه mikrotik ويتم توصيله بنسخة احتياطية مباشرة ، لكن LWT يظل غير متصل بالإنترنت بينما لا يزال mqtt يعمل. أرسل لي يبني للاختبار في الإرادة

هل يمكنك أيضًا رؤية معرف العميل في وسيط MQTT؟
إذا كان يحتوي على "-1" أو شيء ما خلف معرّف العميل ، فهذا يعني أنه يقبل معرّف العميل الجديد.
إذا لم يكن الأمر كذلك ، فقد يكون له علاقة بتغيير معرّفات العملاء التي أجريتها منذ فترة.

لم أحصل على مكان وجود معرف العميل في Mosquitto ، لكن السجلات تظهر كما لو أنه لم يتم فصل أي عميل وتم توصيل عميل جديد ، ربما لأن عملية إلغاء المصادقة وتصديق wifi أسرع من نبضات بروتوكول MQTT.

اتصال جديد بعد إعادة تشغيل كل من 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.

ثاني de-auth

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.

من إعادة الاتصال هذه وعلى بقايا الخط LWT ، تعمل رسائل MQTT بشكل جيد. لاحظ _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.

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

أي تحديث للوضع على هذا؟

كلا ليس بعد.
ولكن نظرًا لأننا نحقق بعض التقدم (أخيرًا) في قضايا الاستقرار الأخرى ، أعتقد أنه سيكون التالي على قائمتي.
شكرا على ping؛)

لقد جعلت تغيير معرف العميل اختياريًا عند إعادة الاتصال. (أدوات => خيارات متقدمة ، بجانب إعدادات MQTT الأخرى)

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

لماذا تغير معرف العميل على أي حال؟

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

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

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

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

أهلا

لقد قمت بتثبيت إصدار 20190110 مؤخرًا. يبدو واعدا. لا توجد مشاكل في LWT بعد 5 أيام من الاختبار. :-)
لدي عقدتين مع تمكين خيار "تغيير MQTT ClientId عند إعادة الاتصال" وبعضها معطل.

أخبار جيدة!

تي