Deconz-rest-plugin: مصابيح ايكيا تفقد الاتصال أحيانًا

نفس الشيء هنا مع 2.05.58. يبدو أن أحد أجهزة الصراف الآلي Tradfri GU10 غير مسؤول:

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

1. أي دليل لماذا؟

يحدد المكون الإضافي REST API الضوء على أنه لا يمكن الوصول إليه ، عندما لا يتلقى استجابة لبضع مرات عند استطلاع الضوء لحالته. سبب عدم تلقي رد حسب الاحتمالية:
أ. تم قطع طاقة الضوء (على سبيل المثال بواسطة مفتاح حائط من القرن العشرين) ؛
ب. شبكة Zigbee بها عطل (على سبيل المثال بسبب التداخل اللاسلكي أو مشاكل التوجيه في الشبكة). في هذه الحالة ، لا يزال الضوء يتفاعل مع أوامر المجموعة ؛
ج. تعطلت البرامج الثابتة للضوء.

1. هل من الممكن استعادة الاتصال غير ذلك ثم فصل / توصيل الطاقة؟

في أ) وج): لا. في ب): نعم.

يحدد المكون الإضافي REST API الضوء على أنه يمكن الوصول إليه ، عندما يتلقى رسالة منه. يؤدي تشغيل الضوء إلى إرسال رسالة _Device Announcement_. في ب) ، عادة ، يعود الضوء تلقائيًا ، عندما ينجح الاستطلاع التالي. يمكنك أيضًا تحديد العقدة في واجهة المستخدم الرسومية deCONZ والضغط على 0 .

نفس المشكلة أيضا في الإصدار 2.05.59.

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

ebaauw شكرا على

أ. تم قطع طاقة الضوء (على سبيل المثال بواسطة مفتاح حائط من القرن العشرين) ؛

لا توجد مفاتيح حائط متاحة لهذه الأضواء ، لذلك لا يمكنني فصل الطاقة عن طريق الخطأ.

ب. شبكة Zigbee بها عطل (على سبيل المثال بسبب التداخل اللاسلكي أو مشاكل التوجيه في الشبكة). في هذه الحالة ، لا يزال الضوء يتفاعل مع أوامر المجموعة ؛

لا تتفاعل الأضواء مع أوامر المجموعة عند فقد الاتصال (يتم تعيين الأضواء إلى Hue Dimmer في تطبيق Phoscon ولا تستجيب على Hue Dimmer عند فقد الاتصال).

ج. تعطلت البرامج الثابتة للضوء.

تم تثبيت البرنامج الثابت 1.2.214 على جميع مواقع IKEA GU10 الخاصة بي. حصلت على 20+ منهم وانقطع ضوء عشوائي دون اتصال ، دعنا نقول واحدة في 2-3 أسابيع.

يمكنك تجربة أحدث إصدار من deCONZ باستخدام https://github.com/dresden-elektronik/deconz-rest-plugin/commit/48d2c39a267b5c6d025577eed7530be27932aa2c.

لقد مررت بنفس التجربة مرتين في الأشهر الماضية مع لمبتين مختلفتين من طراز E14 من ايكيا (IKEA fw 1.2.214).
عملت ركوب الدراجات في كلتا الحالتين بالنسبة لي.

ج. تعطلت البرامج الثابتة للضوء.

عندما لا تتفاعل الأضواء مع أوامر المجموعة ، يبدو أنها تعطل البرنامج الثابت.

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

سيتم تطبيق التكوين الجديد بمجرد تدوير الضوء للطاقة.

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

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

ج. تعطلت البرامج الثابتة للضوء.

عندما لا تتفاعل الأضواء مع أوامر المجموعة ، يبدو أنها تعطل البرنامج الثابت.

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

سيتم تطبيق التكوين الجديد بمجرد تدوير الضوء للطاقة.

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

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

+1 على "ليس بالضرورة مرتبطًا بـ deconz ولكن بالأحرى شبكة Zigbee أو الشركة المصنعة FW" في ارتباط مع تفسير Zigbee القياسي في الشركات المصنعة FW.

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

@ peer69 @ thomas70 هل قمت بتدوير الضوء كما هو مطلوب من قبل manup في https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment -463948127؟

سيتم تطبيق التكوين الجديد بمجرد تدوير الضوء للطاقة.

تلميح جيد ، لم أفعل ذلك. في الوقت الحالي ، كان عليّ أن أعود إلى .58 لسبب آخر (حمل وحدة المعالجة المركزية العالية الذي يحول البوابة غير مستجيب) ، سأحاول ذلك لاحقًا اليوم مع .59 مرة أخرى ودورة الطاقة لجميع مصابيح ايكيا.

أواجه هذه المشكلة أيضًا ، لقد حدثت مرتين لنفس ضوء GU 10. قيد التشغيل حاليًا 2.05.59 ، وقمت بدورة الأضواء بعد التحديث.

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

بعد دورة الكهرباء ، عادت لمباتي من ايكيا. لكن لوح IKEA FLOALT الخاص بي WS لا يزال غير متصل

أواجه نفس المشكلة وقد كنت أفعل ذلك منذ فترة طويلة ، وأقول إن .59 جعل الأمور أسوأ بالنسبة لي. لدي 80 عقدة ، 32 منها عبارة عن مصابيح ومفاتيح Trådfri ، و 5 هي مصابيح Hue والباقي أجهزة مختلفة تعمل ببطارية Xiaomi مثل درجة الحرارة والحركة وكاشف الدخان وما إلى ذلك. كل نوع من الأجهزة لم يستجيب مرة واحدة على الأقل في حالتي إنها ليست فقط أضواء Trådfri ، لكن في ذلك الوقت أواجه مشكلات مع مصابيح Trådfri و Hue.

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

لدي ستة مصابيح Trådfri GU10 في مكان واحد كانت تعمل بشكل مثالي من قبل ، ولكن بعد الترقية إلى .59 والعديد من دورات الطاقة في وقت لاحق ، أصبحت الآن غير مستجيبة تمامًا تقريبًا وسأضطر على الأرجح إلى إعادة ضبطها. الغريب هو أن عدم الاستجابة هذا يبدو أيضًا أنه "يتحرك" من أضواء مختلفة اعتمادًا على الأضواء التي لها طاقة. إذا قمت بقطع الطاقة عن بعض الأضواء غير المستجيبة ، فقد يستغرق الأمر بعض الوقت ثم فجأة لا تريد بعض الإضاءة الأخرى أن تعمل بشكل صحيح. ربما هناك بعض التعويض في مكان ما يكسر الأشياء؟

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

مثير للاهتمام ، هل لديك أيضًا جميع مصابيح Ikea الـ 32 على شبكة Hue؟ أنا أسأل لأن Hue bridge يستخدم الاقتراع فقط ولا يقوم بتكوين تقارير السمات.

هل لديك أيضًا أجهزة توجيه مثل مصابيح Hue أو Ikea على شبكة Xiaomi؟

لدي ستة مصابيح Trådfri GU10 في مكان واحد كانت تعمل بشكل مثالي من قبل ، ولكن بعد الترقية إلى .59 والعديد من دورات الطاقة في وقت لاحق ، أصبحت الآن غير مستجيبة تمامًا تقريبًا وسأضطر على الأرجح إلى إعادة ضبطها. الغريب هو أن عدم الاستجابة هذا يبدو أيضًا أنه "يتحرك" من أضواء مختلفة اعتمادًا على الأضواء التي لها طاقة. إذا قمت بقطع الطاقة عن بعض الأضواء غير المستجيبة ، فقد يستغرق الأمر بعض الوقت ثم فجأة لا تريد بعض الإضاءة الأخرى أن تعمل بشكل صحيح. ربما هناك بعض التعويض في مكان ما يكسر الأشياء؟

حسنًا ، هذا أمر سيء جدًا ، أتساءل حقًا كيف يحدث هذا ، 2.05.59 طريقة "مألوفة" لأضواء Ikea مقارنة بالإصدارات السابقة. التكوين يحدث الآن كما تفعل بوابة Ikea.

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

بالمناسبة الأسئلة المعتادة:

• ما هو إصدار البرنامج الثابت الذي تستخدمه؟
• RaspBee أو ConBee؟
• إذا ConBee هل تستخدم كابل تمديد USB؟

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

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

مثير للاهتمام ، هل لديك أيضًا جميع مصابيح Ikea الـ 32 على شبكة Hue؟ أنا أسأل لأن Hue bridge يستخدم الاقتراع فقط ولا يقوم بتكوين تقارير السمات.

نعم نوعا ما. كان لدي 31 مصباحًا من Ikea على شبكة Hue بالإضافة إلى مصابيح Hue. جهاز Ikea 32 هو منفذ التبديل الذي لم أشتريه في ذلك الوقت.

هل لديك أيضًا أجهزة توجيه مثل مصابيح Hue أو Ikea على شبكة Xiaomi؟

لا ، فقط أجهزة استشعار تعمل بالبطارية

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

لقد حاولت هذا عدة مرات في وقت سابق دون أي تأثير. أما بالنسبة للأجهزة والإعداد ، فأنا أستخدم ConBee مع كابل تمديد USB و 262F0500. نظرًا لأن كل شيء يبدو أنه يعمل بشكل جيد بالنسبة لي الآن ، فقد لا تكون هذه المعلومات ذات فائدة في الوقت الحالي ، لكنني سأحاول عدم القفز إلى أي استنتاجات وترك الشبكة تعمل لبضعة أيام للتأكد من أن المشكلة ليست كذلك إرجاع.

لقد تم تشغيل .59 منذ نهاية الأسبوع الماضي وما زلت أفقد أضواء Ikea العشوائية. (16 لمبة E27 على واجهة المنزل.)
Bulb FW هو نفسه مثل الآخرين الذين لا يزالون على بوابة Ikea.
باستخدام ConBee مع 262F0500 FW.
في نهاية الأسبوع الماضي ، اشتريت أيضًا جسر HUE وكنت على وشك البدء في تحريك الأضواء عندما لاحظت ملاحظة إصدار `` Under the hood '' لـ .59. قررت التأجيل ، لكنها ستعيد النظر في عطلة نهاية الأسبوع القادمة.
سيظل Deconz هو أفضل جهاز تحكم Xiaomi / mi Cube المفضل لدي. لم تفوت أي لفتة حتى الآن.

لقد تم تشغيل .59 منذ نهاية الأسبوع الماضي وما زلت أفقد أضواء Ikea العشوائية. (16 لمبة E27 على واجهة المنزل.)
Bulb FW هو نفسه مثل الآخرين الذين لا يزالون على بوابة Ikea.
باستخدام ConBee مع 262F0500 FW.
في نهاية الأسبوع الماضي ، اشتريت أيضًا جسر HUE وكنت على وشك البدء في تحريك الأضواء عندما لاحظت ملاحظة إصدار `` Under the hood '' لـ .59. قررت التأجيل ، لكنها ستعيد النظر في عطلة نهاية الأسبوع القادمة.
سيظل Deconz هو أفضل جهاز تحكم Xiaomi / mi Cube المفضل لدي. لم تفوت أي لفتة حتى الآن.

لدي نوع من نفس الموقف هنا ، 16 مصباحًا من ايكيا ، 2 منفذ تحكم ايكيا ، قابس Heiman وقابس داخلي وبعض مستشعرات Xiaomi (مستشعرات المكعب / الباب / مستشعر الحركة). لم أواجه مشكلات مع الأجهزة غير التابعة لـ IKEA. ومع ذلك ، لدي حاليًا مشكلات يومية تقريبًا حيث يخرج ضوء ايكيا من الشبكة

أستخدم Conbee مع كبل تمديد USB على البرامج الثابتة 0x26300500 و deCONZ .59

تعمل الأضواء الخاصة بي بشكل جيد منذ فترة حتى الآن ، ولكن منذ يومين ، أصبحت لمبة Trådfri E14 فجأة غير مستجيبة. عادت دورة طاقة واحدة في وقت لاحق إلى الحياة.

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

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

بعد 12 يومًا ، أصبح GU10 آخر غير قابل للوصول ولن يتم الاتصال مرة أخرى بدون دورة طاقة.

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

نفس الشيء هنا ، أمس بعد 6 أيام من الاتصال الذي لا تشوبه شائبة ، فقدت أحد مصابيح Tradfri الخاصة بي .. لم يساعد التشغيل / الإيقاف وإعادة الضبط. لا يزال أصفر في deConz ولكن لا يمكن الاتصال به أو التحكم فيه.

كذلك هنا. بعد بضعة أيام بدون أي مشكلة اليوم ، توقف اثنان من مصابيح GU10 Tradfri عن الاستجابة. تمكنت من إعادة إحياء أحدهما عن طريق الضغط على 0 في واجهة المستخدم الرسومية ، لكن كان عليّ إعادة تشغيل الآخر.
لحسن الحظ ، يبدو أن هذا يحدث فقط لأجهزة الصراف الآلي GU10 ، ولم تواجه لوحات FLOALT الخاصة بي أية مشكلات بعد (في الإعداد الخاص بي ، لا يمكن إعادة تدويرها إلا باستخدام قاطع الدائرة).

القضية استمرت بالنسبة لي كذلك. لقد عانيت الآن من 3-4 لمبات GU10 أخرى تفقد الاتصال بالإضافة إلى أحد أجهزة Hue E27 ومستشعر باب Xiaomi (مغناطيس). بدأت بعض الأضواء في العمل مرة أخرى بعد دورة كهربائية ، والبعض الآخر لا يعمل. الضغط على 0 لا يفعل شيئًا.

من الجدير بالذكر أيضًا أن مستشعر Xiaomi بدأ في العمل مرة أخرى بعد أن قمت بتشغيل جهاز GU10 مجاور وغير مستجيب ، لذا أفترض أن المستشعر كان يتجه عبر هذا الضوء ، لكن ألا ينبغي إعادة توجيهه تلقائيًا إذا كانت هناك أي مشكلات في الاتصال؟

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

مرحبًا ، هل يمكنك تقديم المزيد من الأفكار حول إجمالي الشبكة ، مثل حجم الشبكة والأجهزة الأخرى التي تعمل بالطاقة الكهربائية الموجودة هناك؟

لقد أعدت ترتيب شبكتي المنزلية منذ بضعة أيام ، بما في ذلك الآن:

• 5x IKEA WS GU10 (البرنامج الثابت 1.2.221 ، رمز المنتج LED1537R6GU10EU)
  مع عنوان mac 0x000b57ff ..... (دفعة أقدم)
• 2x IKEA عكس الضوء E27 (البرامج الثابتة 1.2.214)
• 1x IKEA E14 WS light (البرنامج الثابت 1.2.221)
• 1x IKEA repeater (البرنامج الثابت 2.0.019)
• منفذ واحد من ايكيا (البرنامج الثابت 2.0.019)
• عدد 1 أوسرام جو 10
• 1x أوسرام E27 لمبة ملونة
• 1x أوسرام المكونات
• 1x Hue E27 لمبة ملونة
• 1x لمبة لوكس Hue E27 عكس الضوء

ديكونز 2.05.59 ؛ البرامج الثابتة ConBee 0x26300500 (ولكن 0x262f0500 جيدة أيضًا).

لدي 4x FLS-PP lp ولكن تم إيقاف تشغيلها الآن للاختبار ، لأنها تعمل كمكررات إشارة قوية جدًا.

مع المستشعرات والمحولات ، يبلغ إجمالي حجم الشبكة 55.
يتم تشغيل جميع المصابيح دائمًا وحتى الآن لا تظهر أي انقطاع.

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

في وقت سابق من اليوم ، واجهت مشكلة حيث كان Trådfri E14 لا يستجيب بالإضافة إلى Hue E27. بعد دورة الطاقة في E27 ، عاد E14 إلى الحياة أيضًا دون أن ألمسه. ينطبق الأمر نفسه على GU10 التي لا تستجيب والتي يبدو أنها تتداول في أماكن بين الحين والآخر ، لذلك هناك على الأقل جهازي GU10 غير مستجيبين كل يوم ، لكنهما لا يكونان دائمًا نفس الأضواء ، لذا يبدأ البعض في العمل بينما يتعطل البعض الآخر والعكس صحيح.

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

التيار الكهربائي

| الكمية | اكتب | البرامج الثابتة |
| ---------- | ------ | ------------- |
| 30 | Trådfri GU10 عكس الضوء | 1.2.214 |
| 4 | Trådfri GU10 الطيف الأبيض | 1.2.217 |
| 1 | Trådfri E14 أوبال عاكس الضوء | 1.2.217 |
| 1 | منفذ التحكم Trådfri | 1.4.020 |
| 3 | هوى E27 أبيض ولون A19 | 1.29.0_r21169 |
| 2 | هيو E14 أبيض أجواء LTW012 | 1.29.0_r21169 |

البطارية شحنت

الكمية | اكتب | البرامج الثابتة
--------- | ------ | -----------
1 | Trådfri مفتاح تشغيل / إيقاف | 1.4.018
10 | Xiaomi Aqara multisensor (مربع مؤقت / همهمة / عرض) | 20161129
3 | مستشعر الحركة Xiaomi Aqara (الحركة / لوكس) | 20170627
4 | جهاز استشعار المياه Xiaomi Aqara | 20170721
1 | مستشعر حركة هوى | 6.1.0.18912
11 | جهاز استشعار الاتصال Xiaomi Aqara | 20161128
8 | جهاز استشعار الدخان Xiaomi / Honeywell | غير متاح

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

لديّ شبكة بها معظم مصابيح ايكيا ومنفذ Heiman وبعض مستشعرات Xiaomi.

بعض مواصفات شبكة zigbee الخاصة بي:

البرامج الثابتة Conbee 262F0500 مع كابل تمديد على NUC.
deCONZ 2.05.55 في Docker ، لذا فإن أول شيء يجب أن أفعله هو الترقية إلى 2.05.59 على ما أعتقد.

تعمل بالطاقة (24/7)

| الكمية | اكتب | البرامج الثابتة |
| ------------- | ------------- | ------------- |
| 4x | Tradfri E27 أبيض | 1.1.1.0-5.7.2.0 |
| 2x | Tradfri E27 أبيض | 1.2.214 |
| 21x | Tradfri GU10 عكس الضوء | 1.2.214 |
| 3x | أوسرام سمارت + مقبس | 1.04.12 |

البطارية شحنت

| الكمية | اكتب | البرامج الثابتة |
| ------------- | ------------- | ------------- |
| 3x | هوى باهتة التبديل | 5.45.1.17846 |
| 1x | أكارا سمارت سويتش | 20180525 |
| 1x | أكارا سمارت سويتش | 20161128 |
| 1x | عقارا مفتاح لاسلكي مزدوج | 20170411 |
| 1x | TRADFRI عن بعد | 1.2.214 |
| 6x | عقارا مولتيسنسور | 20161129 |
| 10x | مستشعر اتصال عقارة | 20161128 |
| 5x | حساس الحركة | 20170627 |
| 1x | حساس تسرب عقار | 20170721 |
| 1x | حساس اهتزاز عقارة | 20180130 |

أي تحديثات على هذا للنسخة الحالية؟ لقد تم تشغيل .60 لمدة 3 أيام ولم يفقد أي ضوء الاتصال بعد.

لسوء الحظ ، كان لدي بالفعل اتصال مفقود مع لمبة بيضاء Tradfri E27 عادية على .60 وأحدث البرامج الثابتة.

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

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

@ JBS5 أوصي بتحديث 4x Tradfri E27 باللون الأبيض عند 1.1.1.0-5.7.2.0 إلى إصدار أحدث من البرامج الثابتة. إذا كنت أتذكر بشكل صحيح ، فلا يزال هذا هو الإصدار الأول.

jurriaan أي إصدار يحتوي على لمبة بيضاء Tradfri E27؟

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

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

يمكن إيقاف هذا عن طريق النقر على أيقونة CRE في deCONZ وإلغاء تحديد "الموجهات والمنسق".
قد يستحق الاختبار.

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

https://www.reddit.com/r/tradfri/comments/96yiq4/google_home_losing_lamps_and_rooms/e4x1scz/؟context=1

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

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

@ JBS5 أوصي بتحديث 4x Tradfri E27 باللون الأبيض عند 1.1.1.0-5.7.2.0 إلى إصدار أحدث من البرامج الثابتة. إذا كنت أتذكر بشكل صحيح ، فلا يزال هذا هو الإصدار الأول.

لم تفشل مصابيح E27 المزودة بالبرامج الثابتة القديمة خلال الأشهر الستة الماضية بينما فشل الآخرون ...

مثير جدا للاهتمام ، ماذا عن E27 في الإصدار 1.2.214؟

مثير جدا للاهتمام ، ماذا عن E27 في الإصدار 1.2.214؟

لقد فقدوا الاتصال مرة واحدة فقط في الأشهر الماضية.

لقد مرت أسابيع قليلة منذ أن فقدت آخر اتصال GU10 ، هذا بينما ما زلت أستخدم deCONZ 2.05.55 والبرامج الثابتة 262F0500 على Conbee.

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

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

@ peer69 هل حاولت أيضًا تشغيل الضوء فقط؟ عادة لا تكون هناك حاجة لإعادة ضبط المصنع.
أنت على 2.05.60؟ هل يمكنك أيضًا تقديم المزيد من التفاصيل حول شبكتك ، وكم عدد الأجهزة التي تعمل بالطاقة والأضواء؟

@ manup أنا powercycled الضوء. عدة مرات. كان قابلاً للتحكم لمدة 10 ثوانٍ تقريبًا بعد دورة الطاقة ولكن بعد ذلك تحولت إلى عدم الاستجابة مرة أخرى (تومض أضواء حمراء في واجهة المستخدم الرسومية).
في غضون ذلك ، عادت هذه المشكلة مرة أخرى حتى بعد إعادة ضبط المصنع وأثرت أيضًا على ضوء OSRAM آخر. في الوقت الحالي ، كنت أتخلص من مصباحي OSRAM الوحيدين في شبكتي واستبدلهما بمصابيح hue. يمكنني تقديم بعض الاختبارات باستخدام مصابيح ORSAM ولكني سأحتاج إلى بعض الوقت لذلك.

أنا أقوم بتشغيل 2.05.60. يوجد حاليًا 57 عقدة متصلة بالشبكة ، منها 27 جهازًا تعمل بالتيار الكهربائي. أستخدم 13 IKEA GU10 ، 1 لوح IKEA FLOALT ، 2 IKEA E14 ، 3 OSRAM Smart + المقابس ، 3 لمبات تدرج اللون E14 ، 5 لمبات E27 ، 1 شريط إضاءة تدرج اللون.

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

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

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

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

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

واحدة من مواقع IKEA GU10 الخاصة بي لا تستجيب الآن أيضًا.

في المتشمم ، أرى أنه لا يزال "حيًا" إلى حد ما ويرسل رسائل حالة ارتباط NWK ، ولكن من الواضح أنه يعتقد أنه وحده في الشبكة (عدد حالات الارتباط: 0).

لا يستجيب لأوامر البث الأحادي ولكنه يرسل تقرير سمة ZCL دوريًا لمعرف النموذج.

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

سأقوم ببعض الاختبارات ولن أقوم بإعادة تدويرها لفترة من الوقت.

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

لاحظت للتو أن IKEA GU10 الثاني هو أيضًا مسار مشي ، نفس الأعراض مثل الأخرى.

كلا الجهازين لا يستجيبان لطلب عنوان أحادي البث أو البث الجماعي أو ZCP nwk (الضغط على 0).
يرسلون أوامر NWK Link Status فارغة.

أرسل GU10 الثاني أيضًا طلبات ZCL OTA Query Next Image.

يبدو أن الرد لا يأتي من خلال.

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

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

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

خارج الموضوع. كيف تجد نورك في كل هذا؟ لول. لدي إعداد مماثل وكنت مثل ... لا وقت لهذا

بواسطة مماثل يعني + - 50 جهازًا

+ - 50 نوعًا ما طيب. تحتوي إحدى شبكات الاختبار الخاصة بنا على +180 جهازًا مع deCONZ على Raspberry Pi 1 ، وهذا ممتع :)

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

الأضواء لا تزال عالقة.

ملاحظة واحدة مثيرة للاهتمام: لقد قمت بإيقاف تشغيل والد مستشعر حركة Philips Hue (Hue Lux) بحيث يحتاج إلى البحث عن والد جديد. يحاول المستشعر الآن الانضمام مرة أخرى من خلال أحد مصابيح IKEA GU10 العالقة.

الضوء لا يستجيب بأمر مغادرة (مع إعادة الانضمام). لذلك قام بمعالجة طلب إعادة الانضمام!

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

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

التصحيح ، مستشعر حركة Hue ليس عنيدًا جدًا ؛ بعد بضع دقائق ، اختار المستشعر والدًا آخر يعمل (جيد).

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

لقد اختبرت هذا ، لكن للأسف لم ينجح. عندما تكون الأضواء في حالة توقف ، فإنها لن تقوم بمعالجة NWK Leave مع طلب إعادة الانضمام.

لا يمكنني حاليًا إلا أن أستنتج أن ايكيا تحتاج إلى إصلاح إما المشكلة الجذرية للضوء الذي يتوقف عن العمل أو تنفيذ نوع من المراقبة + الفحص الصحي لطبقات NWK / APS من البرنامج الثابت.

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

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

إذن manup ، ما هي أفضل الممارسات لإعادة الانضمام إلى مصباح ايكيا عالق؟

بالنسبة لي ، من الواضح أن دورة طاقة الضوء تعمل بشكل أفضل

manup أعتقد أنه إذا كنت لا تعرف كيف تجعل المريض أفضل ، يجب أن تحاول جعله أسوأ. لذا ، قصف ضوءًا بالأسباب المحتملة للاعتقالات وانظر ما سيحدث.
أيضًا ، ألا تعتمد هذه الأضواء على Ember stack؟ ربما هناك فرق دعم أو منتديات قد تلقي الضوء (يقصد التورية).

بالرسالة إلى ايكيا ، هل تستجيب لطلبات الدعم مثل هذه؟ أم يجب أن نتعاون لكسب بعض الاهتمام؟

بالنسبة لي ، من الواضح أن دورة طاقة الضوء تعمل بشكل أفضل

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

تضمين التغريدة شكرا للنظر في هذا!

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

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

@ peer69 هذا هو أحدث إصدار للبرنامج الثابت:

[
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/190579-ncp572b444.ebl.ota.ota.signed",
    "fw_build_version": 444,
    "fw_file_version_LSB": 444,
    "fw_file_version_MSB": 5720,
    "fw_filesize": 166270,
    "fw_hotfix_version": 2,
    "fw_image_type": 2,
    "fw_major_version": 5,
    "fw_manufacturer_id": 4476,
    "fw_minor_version": 7,
    "fw_type": 1
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/10005777-4.1-TRADFRI-control-outlet-2.0.022.ota.ota.signed",
    "fw_file_version_LSB": 9763,
    "fw_file_version_MSB": 8194,
    "fw_filesize": 204222,
    "fw_image_type": 4353,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/10005778-4.1-TRADFRI-onoff-shortcut-control-2.0.020.ota.ota.signed",
    "fw_file_version_LSB": 1571,
    "fw_file_version_MSB": 8194,
    "fw_filesize": 182078,
    "fw_image_type": 4549,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/10035514-TRADFRI-bulb-ws-1.2.221.ota.ota.signed",
    "fw_file_version_LSB": 5490,
    "fw_file_version_MSB": 4642,
    "fw_filesize": 172734,
    "fw_image_type": 8705,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/10035534-TRADFRI-bulb-ws-gu10-1.2.221.ota.ota.signed",
    "fw_file_version_LSB": 5490,
    "fw_file_version_MSB": 4642,
    "fw_filesize": 172734,
    "fw_image_type": 8707,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/10038562-TRADFRI-sy5882-bulb-ws-2.0.022.ota.ota.signed",
    "fw_file_version_LSB": 9763,
    "fw_file_version_MSB": 8194,
    "fw_filesize": 209790,
    "fw_image_type": 16900,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/1004764-TRADFRI-bulb-cws-1.3.009.ota.ota.signed",
    "fw_file_version_LSB": 38258,
    "fw_file_version_MSB": 4864,
    "fw_filesize": 178366,
    "fw_image_type": 10241,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/159495-TRADFRI-transformer-1.2.245.ota.ota.signed",
    "fw_file_version_LSB": 21874,
    "fw_file_version_MSB": 4644,
    "fw_filesize": 181118,
    "fw_image_type": 16641,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/159695-TRADFRI-bulb-ws-1000lm-1.2.217.ota.ota.signed",
    "fw_file_version_LSB": 30066,
    "fw_file_version_MSB": 4641,
    "fw_filesize": 173246,
    "fw_image_type": 8706,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/159696-TRADFRI-bulb-w-1000lm-1.2.214.ota.ota.signed",
    "fw_file_version_LSB": 17778,
    "fw_file_version_MSB": 4641,
    "fw_filesize": 168318,
    "fw_image_type": 8449,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/159697-TRADFRI-driver-hp-1.2.217.ota.ota.signed",
    "fw_file_version_LSB": 30066,
    "fw_file_version_MSB": 4641,
    "fw_filesize": 173246,
    "fw_image_type": 16898,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/159698-TRADFRI-driver-lp-1.2.217.ota.ota.signed",
    "fw_file_version_LSB": 30066,
    "fw_file_version_MSB": 4641,
    "fw_filesize": 173246,
    "fw_image_type": 16897,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/159699-2.1-TRADFRI-remote-control-1.2.223.ota.ota.signed",
    "fw_file_version_LSB": 13683,
    "fw_file_version_MSB": 4642,
    "fw_filesize": 159806,
    "fw_image_type": 4545,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/159700-TRADFRI-motion-sensor-1.2.214.ota.ota.signed",
    "fw_file_version_LSB": 17778,
    "fw_file_version_MSB": 4641,
    "fw_filesize": 157822,
    "fw_image_type": 4548,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/159701-TRADFRI-wireless-dimmer-1.2.248.ota.ota.signed",
    "fw_file_version_LSB": 34162,
    "fw_file_version_MSB": 4644,
    "fw_filesize": 172926,
    "fw_image_type": 4546,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/10032198-2.1-TRADFRI-gateway-1.8.25.p.elf.sig.ota.signed",
    "fw_filesize": 698748,
    "fw_hotfix_version": 25,
    "fw_major_version": 1,
    "fw_minor_version": 8,
    "fw_req_hotfix_version": 26,
    "fw_req_major_version": 9,
    "fw_req_minor_version": 9,
    "fw_type": 0,
    "fw_update_prio": 5,
    "fw_weblink_relnote": "https://ww8.ikea.com/ikeahomesmart/releasenotes/releasenotesltd.html"
  }
]

التحديثات فقط هي:

• 10005777-4.1-TRADFRI-control-outlet-2.0.022.ota.ota.signed
• 10005778-4.1-TRADFRI-onoff-shortcut-control-2.0.020.ota.ota.signed
• 10032198-2.1-TRADFRI-gateway-1.8.25.p.elf.sig.ota.signed
• 10038562-TRADFRI-sy5882-bulb-ws-2.0.022.ota.ota.signed
• 159699-2.1-TRADFRI- التحكم عن بعد- 1.2.223.ota.ota.signed

لذلك ركز في الغالب على المنافذ / البوابة.

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

أي أخبار لمن يقوم بتحديث deCONZ والبرامج الثابتة لـ Conbee؟

حتى الآن ، سيتم قطع 1 أو 2 GU10s بلا اتصال خلال 2-4 أسابيع. نوعًا ما بشكل متقطع ، لكن powercycling أمر مزعج لأنني لا أملك مفتاح طاقة في أماكن قليلة.

مجرد تحديث البرامج الثابتة إلى 0x26330500 لذلك دعونا نرى.

لسوء الحظ ، اليوم واحد من GU10 الخاص بي غير متوفر ..
استخدام برنامج deCONZ 2.05.64 مع البرامج الثابتة 26330500 على Conbee.

أعتقد أنه تم التوصل إلى أن هذه مشكلة لمبة FW ، حيث نرى نفس المشكلة بالضبط على جسر Philips HUE. لقد لاحظت في تطبيق Trådfri ، قسم ملاحظات الإصدار ، إشارة لمصباح CT v2. ربما هو حتى لمبة HW ذات الصلة؟

ليس لدي أي مشاكل مع 2.05.65 حتى الآن.

نفس الشيء ، لم أواجه هذه المشكلة منذ أسابيع

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

انقطع اتصال عدد قليل من GU10 و E27 قبل بضعة أيام. فقط ركوب الطاقة يعيدهم إلى الإنترنت.

ربما يكون ذا صلة: حدث هذا خلال عطلتي عندما لم تكن هناك أضواء مضاءة لمدة يوم أو 10 أيام.

البرامج الثابتة 26330500 مع deCONZ 2.05.64

ماذا عن هذه القضية لمن قال إنه لم يكن لديه أي مشكلة لبضعة أسابيع قبل أسبوعين؟

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

بقدر ما أستطيع أن أرى ، لا يوجد حتى الآن برامج ثابتة جديدة متاحة لـ Tradfri GU10.

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

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

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

ألاحظ بالمناسبة أن بعض الأضواء تبدو أكثر عرضة لهذه المشكلة. هل تدرك هذا؟

djwlindenaar من الصعب القول ، لكني أعتقد أن نصف الـ 25+ GU10 لم أواجه هذه المشكلة مطلقًا وأنا متأكد من أن البعض واجه المشكلة عدة مرات.

@ peer69djwlindenaar هل الأمر مجموعة تبقي تعمل؟ أصبح GU10 اليوم غير متصل بالإنترنت ولم يستجب حتى على أمر جماعي في المرة الأولى (أمر مجموعة من deCONZ و Hue Dimmer).

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

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

ماذا تقصد ببرهة؟ بضع ساعات أم بضعة أيام؟

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

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

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

كما أن أمر المجموعة أو مفتاح Hue DImmer المرتبط لم يعد قادرًا على تشغيل / إيقاف تشغيل الضوء بعد الآن.

ابتداءً من الليلة الماضية ، لدي 4 أضواء ايكيا في الردهة والتي تنطفئ بعد x مرة بواسطة مؤقت (مساعد منزلي) الآن واحد من المصابيح الأربعة مضاء ولا يمكن إيقاف تشغيلها بواسطة Home Assistant / Deconz. إنه غير متصل وفقًا لـ Deconz ولم ينضم مجددًا خلال 7 ساعات. سأحاول إعادة تدوير الطاقة ومعرفة ما إذا كان ذلك سيؤدي إلى الحيلة.

الضوء لا يعمل: لمبة TRÅDFRI E27 أوبال 1000 لومن بإصدار 1.2.214
المصابيح تعمل: لمبة TRÅDFRI E27 أوبال 1000 لومن بإصدار 1.2.214
البرامج الثابتة: 26330500
ديكونز: V2_05_69

أعتقد أن هناك مشكلة في الأجهزة مع مصابيح الطيف الأبيض Ikea Trafri GU10. أيضًا في إعدادي (بوابة Ikea متصلة عبر واجهة برمجة تطبيقات محلية بالمساعد المنزلي) ، ما لا يقل عن نصف لمبة 17 الخاصة بي تصبح غير متصلة بالإنترنت كل يومين. الحل الوحيد هو تشغيل المصابيح الكهربائية.

قد يكون هذا هو السبب الذي من أجله أطلقت Ikea إصدارًا جديدًا للأجهزة يقوم بتشغيل إصدار مختلف من البرنامج الثابت (2. * بدلاً من 1. *).

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

لست متأكدًا من الضمان ، لكنني أخطط لطلب الاستبدال بالإصدار الجديد.

أعتقد أن هناك مشكلة في الأجهزة مع مصابيح الطيف الأبيض Ikea Trafri GU10. أيضًا في إعدادي (بوابة Ikea متصلة عبر واجهة برمجة تطبيقات محلية بالمساعد المنزلي) ، ما لا يقل عن نصف لمبة 17 الخاصة بي تصبح غير متصلة بالإنترنت كل يومين. الحل الوحيد هو تشغيل المصابيح الكهربائية.

قد يكون هذا هو السبب الذي من أجله أطلقت Ikea إصدارًا جديدًا للأجهزة يقوم بتشغيل إصدار مختلف من البرنامج الثابت (2. * بدلاً من 1. *).

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

لست متأكدًا من الضمان ، لكنني أخطط لطلب الاستبدال بالإصدار الجديد.

لست متأكدًا مما إذا كان مرتبطًا بنوع واحد فقط ، لأنني أستخدم GU10 الأبيض الدافئ ، وليس الطيف الأبيض.

واجهت نفس المشكلة مع اثنين من IKEA GU 10 WW اليوم. لم يساعد ركوب الطاقة. لقد ساعد في إعادة تدوير الطاقة وإعادة تشغيل deconz. ربما بعض قضية جدول الجار؟ كلا المصباحين في مجموعة من اثنين ويتم التحكم فيهما دائمًا كمجموعة.

يا لها من مصادفة أن هذا يحدث في عدة منشآت هذه الأيام .. أم شيء آخر يحدث؟

ههههههههه

ما هو إصدار البرامج الثابتة deCONZ و conbee الذي تستخدمه؟

انا استخدم:
ديكونز V2_05_66
البرامج الثابتة 26330500

نفس البرامج الثابتة هنا. deCONZ الإصدار 2.05.69.

وفقد اللون الأبيض الدافئ Tradfri GU10 الآخر اتصاله ..

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

http://fw.test.ota.homesmart.ikea.net/feed/version_info.json

10046695-1.1-TRADFRI-light-unified-w-2.1.022.ota.ota.signed 10038562-TRADFRI-sy5882-bulb-ws-2.0.022.ota.ota.signed 10038562-TRADFRI-sy5882-bulb-ws-2.0.023.ota.ota.signed 10035514-TRADFRI-bulb-ws-2.3.007.ota.ota.signed 10035534-TRADFRI-bulb-ws-gu10-2.3.007.ota.ota.signed 159695-TRADFRI-bulb-ws-1000lm-2.3.007.ota.ota.signed

manup هذه لأضواء GU10 ذات الطيف الأبيض ، وأعتقد أنها للإصدار الجديد؟ https://www.ikea.com/nl/nl/p/tradfri-led-lamp-gu10-400-lumen-draadloos-dimbaar-warm-wit-60420041/

ربما يمكن استخدام 10046695-1.1-TRADFRI-light-unified-w-2.1.022.ota.ota.signed لهم. سأختبرها على أحد مصابيح IKEA E27 القابلة للتعتيم ، وآمل أن تكون أسوأ حالة هي التحطم ولكن لا تحترق :)

لقد حاولت تعيين الملف يدويًا ولكن المصباح لم يُشاهد لالتقاط التحديث (لا يبدأ).

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

البرامج الثابتة Conbee: 264A0700
البرامج الثابتة الخفيفة: 1.2.214

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

لقد أدركت للتو ، ربما ، إضافة مثيرة للاهتمام لهذه المشكلة.

تم تجهيز العديد من الغرف بمواقع Tradfri GU10 المتعددة ومعظم الغرف بها مفتاح Hue Dimmer Switch ، مع ارتباط مباشر بـ GU10 في الغرفة التي تم إنشاؤها عن طريق إضافتها إلى مجموعة Hue Dimmer Switch في تطبيق Phoscon.

• فقط GU10's ذات الربط المباشر مع Hue Dimmer Switch تصبح غير متصلة بالإنترنت بين الحين والآخر وتحتاج إلى دورة طاقة للعودة إلى الاتصال بالإنترنت.
• GU10 بدون ربط مباشر مع Hue Dimmer Switch لا تنقطع الاتصال بالإنترنت.

لا يبدو أن هذا هو الحال بالنسبة لي. حتى الآن ، يبدو أن لمبات Hue هي الوحيدة التي تتمتع بقدر كبير من المرونة. جميع أنواع أجهزة ايكيا (GU10 ، E14 ، FLOALT Panel) وأجهزة Osram (المصابيح ، Lighstrips وأعمدة الحديقة) التي أملكها فشلت. خاصة أن أجهزة Osram تفشل تمامًا ، ودورة الطاقة لا تفعل شيئًا. يجب إزالتها وإصلاحها وهو أمر مؤلم لهذه الأجهزة.

لقد أمضيت بعض الأيام أفكر في استبدال جميع أجهزتي zigbee بأجهزة لطريقي بتثبيت KNX باهظ الثمن بعد فشل العديد من الأجهزة وفشل الترحيل إلى Conbee II stick أيضًا بسبب zll-db تالف إلى حد ما. ثم اتخذت النهج الجذري لإنشاء كل شيء من الصفر. أعدت ضبط البوابة وأصلحت جميع الأجهزة. بالنسبة لأجهزة ايكيا ، كان هذا أسهل بكثير مما كان عليه من قبل. في الماضي كان علي نقلهم بالقرب من البوابة ، وإعادة تعيينهم عدة مرات ، واستخدام رابط اللمس لجعلهم يستجيبون - لا شيء من هذا القبيل هذه المرة. لقد قمت فقط بإعادة ضبط المصابيح وتم إقرانها دون أي مشاكل. ومع ذلك ، فإن القيام بذلك لـ 70 جهازًا كان بمثابة ألم ، وبعض مستشعرات xiaomi جعلت الأمر أكثر صعوبة قليلاً من أجهزة ايكيا. لكن هذا يجعلني أعتقد بالفعل أنه قد يكون لدي شبكة أكثر استقرارًا الآن. ومع ذلك ، لم يفشل شيء ، لكنني سأخبرك إذا حدث ذلك.

لقد مر وقت طويل منذ أن قمت بتحديث raspbee ، كانت إصداري القديم تواجه مشكلات في قراءة درجة حرارة الأضواء ، لذلك قررت التحديث إلى أحدث البرامج الثابتة وأحدث برنامج deCONZ. حصلت على مصباحين فقط (أوسرام 73674). 1 ضوء (ربما عشوائي) يفقد الاتصال بعد بضع دقائق مع أحدث إصدار من deCONZ ولا بد لي من إيقاف تشغيله وتشغيله يدويًا مرة أخرى. الإصدار الوحيد الذي وجدته كان قادرًا على قراءة درجات الحرارة ولم يفقد الأضواء هو deconz-2.04.40-qt5.deb وهو قديم جدًا ، ولكنه يعمل للاستخدام الأساسي.

يحدث كثيرًا مؤخرًا بالنسبة لي أيضًا مع اللون الفردي IKEA GU10. نوع من الألم في المؤخرة. لكن العقد لا تصبح حمراء بالنسبة لي ، فقط رمادية اللون. سوف يتفاعلون مع ضغطات الأزرار البعيدة ، ولكن ليس عبر Phoscon أو HA.

هل تستمر deCONZ في تحديث حالة الضوء عندما تتحكم بها من جهاز التحكم عن بُعد؟

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

ما زلت أواجه نفس المشكلة من حين لآخر (~ مرة واحدة في الأسبوع) مع Xiaomi Curtain Controller (وهو جهاز توجيه ZigBee). _Device Announment_ بعد تدوير الطاقة ، يتسبب الجهاز في قيام deCONZ بإعادة تعلم المسار.

تم تقديم مشكلات التوجيه هذه مع دعم اكتشاف التوجيه الذي تستخدمه مصابيح Trådfri ، لذلك يبدو 2.04.40 صحيحًا.

ebaauw عندما لا يتوفر الضوء ، تعمل أوامر المجموعة بالنسبة لي ولكن لفترة محدودة فقط. بعد ذلك ، يظل الضوء مضاءًا أو مطفئًا ولا يستجيب لأمر المجموعة بعد الآن. استخدام Hue Dimmer Switch (الربط الذي تم إنشاؤه عن طريق إضافة الأضواء إلى المجموعة الافتراضية التي تم إنشاؤها عند إقران Hue Dimmer Switch في تطبيق Phoscon).

هل تستمر deCONZ في تحديث حالة الضوء عندما تتحكم بها من جهاز التحكم عن بُعد؟

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

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

ما زلت أواجه نفس المشكلة من حين لآخر (~ مرة واحدة في الأسبوع) مع Xiaomi Curtain Controller (وهو جهاز توجيه ZigBee). _Device Announment_ بعد تدوير الطاقة ، يتسبب الجهاز في قيام deCONZ بإعادة تعلم المسار.

تم تقديم مشكلات التوجيه هذه مع دعم اكتشاف التوجيه الذي تستخدمه مصابيح Trådfri ، لذلك يبدو 2.04.40 صحيحًا.

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

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

إنها مشكلة متقطعة. لم أتمكن من إعادة إنتاجه في الإرادة ، انظر # 849. في الواقع ، تستند جميع قواعدي للتحكم في الأضواء إلى إجراءات /groups ، لذلك لم ألاحظ المشكلة من قبل ، حتى حصلت على وحدة التحكم في الستارة.

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

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

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

بالنسبة لي ، يحدث هذا أيضًا مع الأضواء التي كانت مضاءة أو قبل بضع دقائق / ساعات فقط.

كما تم نشر بعض الردود أعلاه ، فإن معظم مصابيح GU10 الخاصة بي مرتبطة بمفتاح Hue Dimmer Switch (3-8 في غرفة بها مفتاح Hue Dimmer Switch). قلة ليست كذلك ، وهؤلاء متصلون بالإنترنت منذ شهور. لم يذهب أحد منهم غير متوفر. صدفة أم لا .. ما رأيك في هذاebaauw؟

ترتبط معظم مصابيح GU10 الخاصة بي بمفتاح Hue Dimmer Switch

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

لاحظ أن "الربط" في مصطلحات ZigBee يعني: إنشاء إدخال في جدول ربط الجهاز إلى عنوان ZigBee لإرسال الأوامر من المجموعة المرتبطة إليه. أعتقد أن مجموعات (العميل!) _OnOff_ و _Level Control_ لمفتاح التعتيم الخاص بك مرتبطة بمجموعة (بواسطة المكون الإضافي deCONZ REST API). تم إدراج هذه المجموعة في مورد ZHASwitch ضمن config.group . بعد ذلك ، تمت إضافة الضوء إلى هذه المجموعة. مجموعات ZigBee هي أشبه بعناوين البث المتعدد ، لذلك ربما يكون من الأصح القول إن الضوء قد اشترك في رسائل هذه المجموعة.

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

ترتبط معظم مصابيح GU10 الخاصة بي بمفتاح Hue Dimmer Switch

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

لاحظ أن "الربط" في مصطلحات ZigBee يعني: إنشاء إدخال في جدول ربط الجهاز إلى عنوان ZigBee لإرسال الأوامر من المجموعة المرتبطة إليه. أعتقد أن مجموعات (العميل!) _OnOff_ و _Level Control_ لمفتاح التعتيم الخاص بك مرتبطة بمجموعة (بواسطة المكون الإضافي deCONZ REST API). تم إدراج هذه المجموعة في مورد ZHASwitch ضمن config.group . بعد ذلك ، تمت إضافة الضوء إلى هذه المجموعة. مجموعات ZigBee هي أشبه بعناوين البث المتعدد ، لذلك ربما يكون من الأصح القول إن الضوء قد اشترك في رسائل هذه المجموعة.

لا ، لم أنشئ رابطًا في لوحة de _Bind Dropbox_ في واجهة المستخدم الرسومية deCONZ.

هل تقصد أن إضافة الأضواء إلى هذه المجموعات في تطبيق Phoscon لا يؤدي إلى ارتباط بين البعيد والضوء (الأضواء)؟ افترضت ذلك ، لأن تبديل الأضواء المضافة باستخدام Hue Dimmer Switch يكون ممكنًا أيضًا عندما تكون حاوية docker deCONZ أو NUC بالكامل غير متصلة بالإنترنت.

حسنًا ، لدي بصلة لا تستجيب الآن. كانت رمادية اللون في bth deCONZ و Phoscon.

كان يتفاعل مع الأوامر عن بُعد وأيضًا عندما حركت شريط التمرير في وضع "المجموعة" في Phoscon ،

هل تستمر deCONZ في تحديث حالة الضوء عندما تتحكم بها من جهاز التحكم عن بُعد؟

ليس في البداية لأنه كان معطلاً.

ثم حاولت بعد ذلك "إعادة تعيين العقدة المحددة" في deCONZ ، وبعد ذلك بقيت لبضع دقائق غير معطلة بعد الآن على الرغم من عدم وجود زر الراديو العنقودي بعد الآن في deCONZ.

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

بعد فترة اختفت مرة أخرى باللون الرمادي في فوسكون.

ثم حاولت بعد ذلك قطع الكهرباء لبضع دقائق. لم يساعد.

حدث موقف مثير الليلة:

أحد أضواء GU10 البيضاء الدافئة من Tradfri غير متصل مرة أخرى منذ بضع ساعات. يعمل مفتاح Hue Dimmer Switch المرتبط بـ 8 GU10s بما في ذلك الذي هو غير متصل الآن ، على تشغيل / إيقاف تشغيل ، وفقًا لـ deconz ، GU10 غير المتصل. غريب بما فيه الكفاية ، هذا فقط.
لا تستجيب GU10s الأخرى لمفتاح Hue Dimmer Switch المرتبط.

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

عندما يكون GU10 غير متصل بالإنترنت من قبل ، يقوم مفتاح Hue Dimmer Switch بتبديل / إيقاف تشغيل جميع الأضواء في المجموعة ، بما في ذلك ، وفقًا لـ deconz ، GU10 غير المتصل بالإنترنت (عاجلاً أم آجلاً ، وفقًا لـ deconz ، يتوقف GU10 غير المتصل أيضًا عن الاستماع إلى أوامر المجموعة إما).

هل يمكن أن يكون هذا مفيدا؟

\ تحرير: "اسم" GU10 غير المتصل هذا في deCONZ عبر VNC فارغ.

عند ملء هذا مرة أخرى ، لم يتم تعيينه (لم يتم القيام بذلك هنا ، عادةً في تطبيق Phoscon):

لا يزال أصفر إما:

لا يؤدي الضغط على "0" أو "إعادة تعيين العقدة المحددة" إلى إعادة اتصال GU10 بالإنترنت.

تحرير 2 : بعد حوالي 24 ساعة من توقف GU10 عن الاتصال بالإنترنت ، لم يعد GU10 يستجيب لمحول Hue Dimmer Switch المرتبط بعد الآن كما هو موضح من قبل. لا يستجيب أي من مصابيح GU10 في المجموعة الآن. العقدة في deCONZ GUI لا تزال صفراء ولكن الاسم باللون الرمادي.
بعد إعادة تدوير ضوء GU10 غير المتصل بالإنترنت ، تستجيب جميع الأضواء الثمانية في المجموعة ، بما في ذلك التي كانت غير متصلة بالإنترنت ، لمفتاح Hue Dimmer Switch المرتبط مرة أخرى.

manup هذا السلوك / الموقف مختلف تمامًا عن السابق ، فربما يساعد ذلك في معرفة السبب؟

لقد أدركت للتو ، ربما ، إضافة مثيرة للاهتمام لهذه المشكلة.

تم تجهيز العديد من الغرف بمواقع Tradfri GU10 المتعددة ومعظم الغرف بها مفتاح Hue Dimmer Switch ، مع ارتباط مباشر بـ GU10 في الغرفة التي تم إنشاؤها عن طريق إضافتها إلى مجموعة Hue Dimmer Switch في تطبيق Phoscon.

• فقط GU10's ذات الربط المباشر مع Hue Dimmer Switch تصبح غير متصلة بالإنترنت بين الحين والآخر وتحتاج إلى دورة طاقة للعودة إلى الاتصال بالإنترنت.
• GU10 بدون ربط مباشر مع Hue Dimmer Switch لا تنقطع الاتصال بالإنترنت.

لسوء الحظ ، أحد أجهزة Tradfri GU10 Warmwhite الخاصة بي بدون مفتاح Hue Dimmer Switch غير متصل منذ أمس ..

ما زلت أتساءل عن سبب عدم اتصال بعض مواقع GU10 (نفس اللون الأبيض الدافئ) مطلقًا.
\ تحرير : أيضًا GU10 الذي كان متصلاً بالإنترنت لعدة أشهر ، غير متصل منذ أمس.

اشتريت Tradfri Hub في نهاية الأسبوع الماضي وقمت بإقران جميع نقاط GU10 في غرفة واحدة بها. لنرى ماذا سيحدث في الأسابيع القادمة ..

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

هل يمكنني تقديم أي نوع من السجلات أو المعلومات لتسهيل عملية استكشاف الأخطاء وإصلاحها؟

tubalainen ماذا تقصد بعدم الاستجابة؟ هل يستجيبون بأنفسهم هل يحتاجون إلى دورة طاقة؟

tubalainen ماذا تقصد بعدم الاستجابة؟ هل يستجيبون بأنفسهم هل يحتاجون إلى دورة طاقة؟

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

هل هناك أي تقدم في هذا؟ لقد أصبح الأمر سخيفًا بعض الشيء مع تحول أضواء GU10 إلى اللون الرمادي :(

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

ليس لدي أي مفاتيح تشغيل / إيقاف تشغيل على الحائط أو ستائر ايكيا هنا ولدي مشكلة.

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

في نهاية الأسبوع الماضي ، أضفت بضع لمبات E27 جديدة والآن العديد من GU10s الخاصة بي تتسرب طوال الوقت مرة أخرى.

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

في نهاية الأسبوع الماضي ، أضفت بضع لمبات E27 جديدة والآن العديد من GU10s الخاصة بي تتسرب طوال الوقت مرة أخرى.

ما هي مصابيح GU10 التي لديك وما هي البرامج الثابتة التي قمت بتثبيتها؟

اشتريت Tradfri Hub في نهاية الأسبوع الماضي وقمت بإقران جميع نقاط GU10 في غرفة واحدة بها. لنرى ماذا سيحدث في الأسابيع القادمة ..

عندما استخدمت بوابة Tradfri ، كان لدي لمبات غير مستجيبة كل يوم تقريبًا (طيف Tradfri GU10 الأبيض ، الجيل الأول). لقد تحولت إلى جسر Philips Hue وبدا أن المشكلة قد ولت ، ولكن بعد أسبوعين أصبحت لمبة واحدة غير مستجيبة (كالعادة ، حلّت دورة الطاقة المشكلة).

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

لا أمتلك جهاز GU10 واحدًا وما زلت أعاني من المشكلة.

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

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

لدي 8 GU-10 بعمر 18 شهرًا تقريبًا. أصبح أحدهم رماديًا مرة واحدة في ذلك الوقت. إنهم جميعًا في نفس الغرفة التي يوجد بها العصا الصغيرة. لدي بعض المصابيح 980 لومن عمرها 3 سنوات. المسافة الأبعد عن gw عبر قفز gu 10 تتحول إلى اللون الرمادي ربما مرة كل أسبوعين.
tubalainen قد يكون على شيء ما.

بجانب الشخص الذي يتحول إلى اللون الرمادي ، لديّ أوسرام لم يسبق له مثيل.

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

هنا دليل آخر محتمل. لم يكن لدي أبدًا أي مصابيح تتحول إلى اللون الرمادي على الإطلاق (في أكثر من عام من وقت التشغيل مع 8 مصابيح من ايكيا) ، ولكن بعد ذلك قمت بتحديث المكون الإضافي Home Assistant deconz من 3.8 إلى 3.9 وفي غضون يومين كان لدي اثنين من GU10 باللون الرمادي ، أنا استعادة نسخة احتياطية من الإصدار 3.8 من المكون الإضافي ولم تكن هناك مشاكل منذ ذلك الحين. الشيء الغريب هو أن المكون الإضافي 3.8 و 3.9 يستخدم نفس إصدار deconz (إذا كان سجل التغيير كاملاً). ومع ذلك ، حتى في فوسكون ، لم يكن من الممكن الوصول إلى المصابيح. كل هذا غريب إلى حد ما ، لكنني أفترض أن الإصدار 3.9 من المكوِّن الإضافي يقدم نوعًا من طلب deconz الذي يجعل مصابيح ايكيا غير مستقرة.

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

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

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

هل تستمر قيادة المجموعة في العمل بعد دعنا نقول بضعة أيام / أكثر من أسبوع؟
في حالتي: عاجلاً أم آجلاً ، يتوقف الضوء أيضًا عن الاستماع إلى أوامر المجموعة.

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

هل تستمر قيادة المجموعة في العمل بعد دعنا نقول بضعة أيام / أكثر من أسبوع؟
في حالتي: عاجلاً أم آجلاً ، يتوقف الضوء أيضًا عن الاستماع إلى أوامر المجموعة.

نعم ، يبدو أنه يعمل بشكل جيد مع مرور الوقت أيضًا. لكن لدي نظرية عن الخطأ. عندما يتم توجيه العقد الضوئية من خلال لمبة TRADFRI E27 WS opal 1000lm ، تحدث المشكلات. لذا قمت أمس بإيقاف تشغيل الجهازين اللذين لديهما في شبكتي. منذ ذلك الحين يبدو أن كل شيء يعمل بشكل مثالي.

لدي لمبة TRADFRI GU10 WS 400lm ، لمبة TRADFRI E14 CWS أوبال 600lm ومصباح TRÅDFRI E27 CWS أوبال 600lm. لا يبدو أنها تسبب أي مشكلة.

يمكن أن يكون مرتبطًا بالبرامج الثابتة الأقدم من Trådfri. تأتي المصابيح الأحدث مع أحدث البرامج الثابتة ، لكنني لا أعتقد أن ايكيا قد نشرت برنامجًا ثابتًا محدثًا لجميع مصابيح الجيل الأول. ليس لدي أي نقاط Trådfri GU10 ، ولكن بواسطة لمبة CWS تلقيت تحديثًا للبرامج الثابتة. لم أفعل لمبتي الخافتة 1000lm ؛ لست متأكدًا من لمبة الطيف الأبيض.

يمكن أن يكون مرتبطًا بالبرامج الثابتة الأقدم من Trådfri. تأتي المصابيح الأحدث مع أحدث البرامج الثابتة ، لكنني لا أعتقد أن ايكيا قد نشرت برنامجًا ثابتًا محدثًا لجميع مصابيح الجيل الأول. ليس لدي أي نقاط Trådfri GU10 ، ولكن بواسطة لمبة CWS تلقيت تحديثًا للبرامج الثابتة. لم أفعل لمبتي الخافتة 1000lm ؛ لست متأكدًا من لمبة الطيف الأبيض.

لمبة TRADFRI الخاصة بي GU10 WS 400lm موجودة على نفس البرنامج الثابت ، 2.0.022. لا يبدو أنها تسبب مشاكل (حتى الآن :))

يمكن أن يكون مرتبطًا بالبرامج الثابتة الأقدم من Trådfri. تأتي المصابيح الأحدث مع أحدث البرامج الثابتة ، لكنني لا أعتقد أن ايكيا قد نشرت برنامجًا ثابتًا محدثًا لجميع مصابيح الجيل الأول. ليس لدي أي نقاط Trådfri GU10 ، ولكن بواسطة لمبة CWS تلقيت تحديثًا للبرامج الثابتة. لم أفعل لمبتي الخافتة 1000lm ؛ لست متأكدًا من لمبة الطيف الأبيض.

أنا موافق. يحتوي الإصدار الأول من مصابيح Ikea (على 1. * البرامج الثابتة) على بعض أخطاء البرامج / الأجهزة التي لا تؤثر على التكرارات الثانية (في 2. *).

للأسف ، يبدو أن Ikea لم يعد يدعم الإصدار الأصلي ولن يقدم أي تحديث للبرامج الثابتة. في الوقت نفسه ، لا يمكن إعادة المصابيح واستبدالها بالمصابيح الجديدة (لقد جربت ، في المملكة المتحدة).

يمكن أن يكون مرتبطًا بالبرامج الثابتة الأقدم من Trådfri. تأتي المصابيح الأحدث مع أحدث البرامج الثابتة ، لكنني لا أعتقد أن ايكيا قد نشرت برنامجًا ثابتًا محدثًا لجميع مصابيح الجيل الأول. ليس لدي أي نقاط Trådfri GU10 ، ولكن بواسطة لمبة CWS تلقيت تحديثًا للبرامج الثابتة. لم أفعل لمبتي الخافتة 1000lm ؛ لست متأكدًا من لمبة الطيف الأبيض.

أنا موافق. يحتوي الإصدار الأول من مصابيح Ikea (على 1. * البرامج الثابتة) على بعض أخطاء البرامج / الأجهزة التي لا تؤثر على التكرارات الثانية (في 2. *).

للأسف ، يبدو أن Ikea لم يعد يدعم الإصدار الأصلي ولن يقدم أي تحديث للبرامج الثابتة. في الوقت نفسه ، لا يمكن إعادة المصابيح واستبدالها بالمصابيح الجديدة (لقد جربت ، في المملكة المتحدة).

لدي لمبات cws في 1.3.009. لا يبدو أنها تسبب مشاكل.

تحديث:

يبدو أن لمبات ايكيا الأخرى تسبب مشكلة أيضًا.

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

لا يبدو أنني أمتلك أي أجهزة 2.x.
بعض GU10 تعمل بشكل جيد ، والبعض الآخر لا. بدأت في استبدال العيوب بأخرى "جديدة" اشتريتها بعد بضعة أشهر. يبدو أنهم يقومون بتشغيل نفس البرنامج الثابت على الرغم من وجود رقم "1808 -S" مطبوع على المقبس بينما تحتوي البرامج "الأحدث" على "1729-S".
لقد استبدلت 3 لمبات حتى الآن ولم تحدث مشكلات جديدة لمدة أسبوعين. لم أواجه مشكلة GU10 فقط ولكن أيضًا مع لوحة FLOALT التي لم أستبدلها.

لا يبدو أنني أمتلك أي أجهزة 2.x. بعض GU10 تعمل بشكل جيد ، والبعض الآخر لا. بدأت في استبدال العيوب بأخرى "جديدة" اشتريتها بعد بضعة أشهر. يبدو أنهم يقومون بتشغيل نفس البرنامج الثابت على الرغم من وجود رقم "1808 -S" مطبوع على المقبس بينما تحتوي البرامج "الأحدث" على "1729-S". لقد استبدلت 3 لمبات حتى الآن ولم تحدث مشكلات جديدة لمدة أسبوعين. لم أواجه مشكلة GU10 فقط ولكن أيضًا مع لوحة FLOALT التي لم أستبدلها.

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

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

لدي لمبة TRADFRI GU10 WS 400lm ، لمبة TRADFRI E14 CWS أوبال 600lm ومصباح TRÅDFRI E27 CWS أوبال 600lm. لا يبدو أنها تسبب أي مشكلة.

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

هل هناك أي أنشطة مخطط لها للنظر في هذا؟ سأقوم بنقل جميع أجهزة IKEA الخاصة بي إلى بوابة hue الخاصة بي أثناء حل هذه المشكلة.

تتوقف العقد عن الاستجابة للأوامر.

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

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

(ليس؟) يقطع عقدة توجيه IKEA بطريقة ما المسار من و / أو اكتشاف المسار بواسطة البوابة إلى العقد الأخرى.

هل هناك أي أنشطة مخطط لها للنظر في هذا؟

سيكون عليك أن تطلب دعم dresden elektronik. تتم معالجة التوجيه بواسطة البرامج الثابتة RaspBee / ConBee (وبرنامج deCONZ الأساسي؟). لا يمكننا فعل أي شيء حيال ذلك في المكون الإضافي REST API.

اشتريت Tradfri Hub في نهاية الأسبوع الماضي وقمت بإقران جميع نقاط GU10 في غرفة واحدة بها. لنرى ماذا سيحدث في الأسابيع القادمة ..

ربما يكون من المبكر القول ، لكن منذ 29 يومًا قمت بنقل كل Tradfri GU10s (8x Warmwhite - 1.2.214) من غرفة واحدة إلى Tradfri Hub ، ولم يعد أي منها غير مستجيب حتى الآن.

ربما يكون من المبكر القول ، لكن منذ 29 يومًا قمت بنقل كل Tradfri GU10s (8x Warmwhite - 1.2.214) من غرفة واحدة إلى Tradfri Hub ، ولم يعد أي منها غير مستجيب حتى الآن.

أتوقع ذلك. لا ترجع المشكلة كثيرًا إلى الأجهزة من جهة تصنيع واحدة ، كما هو الحال بسبب التفاعل بين الأجهزة من مختلف الشركات المصنعة ، مما يؤدي إلى تفسير معيار ZigBee بشكل مختلف. لهذا السبب تدعم معظم المحاور / البوابات / الجسور أجهزتهم الخاصة فقط. قد تكون التجربة الأكثر إثارة للاهتمام هي توصيل نقاط Trådfri إلى جسر Hue أو بوابة OSRAM.

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

تتوقف العقد عن الاستجابة للأوامر.

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

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

طالما أنني أرسل أوامر جماعية فقط ، يبدو أن كل شيء يعمل بشكل جيد.

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

(ليس؟) يقطع عقدة توجيه IKEA بطريقة ما المسار من و / أو اكتشاف المسار بواسطة البوابة إلى العقد الأخرى.

هل هناك أي أنشطة مخطط لها للنظر في هذا؟

سيكون عليك أن تطلب دعم dresden elektronik. تتم معالجة التوجيه بواسطة البرامج الثابتة RaspBee / ConBee (وبرنامج deCONZ الأساسي؟). لا يمكننا فعل أي شيء حيال ذلك في المكون الإضافي REST API.

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

ربما يكون من المبكر القول ، لكن منذ 29 يومًا قمت بنقل كل Tradfri GU10s (8x Warmwhite - 1.2.214) من غرفة واحدة إلى Tradfri Hub ، ولم يعد أي منها غير مستجيب حتى الآن.

أتوقع ذلك. لا ترجع المشكلة كثيرًا إلى الأجهزة من جهة تصنيع واحدة ، كما هو الحال بسبب التفاعل بين الأجهزة من مختلف الشركات المصنعة ، مما يؤدي إلى تفسير معيار ZigBee بشكل مختلف. لهذا السبب تدعم معظم المحاور / البوابات / الجسور أجهزتهم الخاصة فقط. قد تكون التجربة الأكثر إثارة للاهتمام هي توصيل نقاط Trådfri إلى جسر Hue أو بوابة OSRAM.

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

لقد فعلت ذلك للتأكد من عدم ارتباطه بالبرنامج الثابت 1.2.214 من GU10 القديم والذي تم ذكره كسبب محتمل هنا كثيرًا (والسبب المحتمل لإنشاء إصدار جديد من GU10).
ربما فيما يتعلق بالاتصال عبر جهاز توجيه آخر.

سأفكر في إقران أضواء GU10 الأخرى الخاصة بي (أيضًا دافئ 1.2.214) إلى Tradfri Hub (أيضًا تلك الموجودة في الطابق 2de / 3)

هل هناك أي تقدم في هذا؟ لقد أصبح الأمر سخيفًا بعض الشيء مع تحول أضواء GU10 إلى اللون الرمادي :(

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

لم يكن لدي مفتاح تشغيل / إيقاف fyrtur في الشبكة منذ آخر مشاركة لي ولم يكن لدي أي تسرب في ذلك الوقت. قد تكون مصادفة ...؟

هل هناك أي تقدم في هذا؟ لقد أصبح الأمر سخيفًا بعض الشيء مع تحول أضواء GU10 إلى اللون الرمادي :(
أعتقد أنني رأيت شخصًا يذكر وحدة تحكم الستارة أو مفتاح تشغيل / إيقاف. لقد حدث لي في الواقع أن المشاكل تفاقمت كثيرًا في الوقت الذي حصلت فيه على ستائر FYRTUR. كان هذا أيضًا أول زر ikea أضفته إلى الشبكة ... لا ...

لم يكن لدي مفتاح تشغيل / إيقاف fyrtur في الشبكة منذ آخر مشاركة لي ولم يكن لدي أي تسرب في ذلك الوقت. قد تكون مصادفة ...؟

لا ، ليس لدي أي ستائر Tradfri تعمل على تشغيل / إيقاف أو Tradfri ولدي هذه المشكلة.
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment -562299982

بطريق الخطأ أغلقت هذه القضية. إعادة الفتح.

قد تكون التجربة الأكثر إثارة للاهتمام هي توصيل نقاط Trådfri إلى جسر Hue أو بوابة OSRAM.

واجهت نفس المشكلة مع مصابيح Trådfri (الجيل الأول) المتصلة بمحور Trådfri. اختفت المشكلة تمامًا عندما قمت بنقل جميع المصابيح إلى جسر هيو.

راجع للشغل - ما زلت مقتنعًا بأن الجيل الأول من لمبات Trådfri معطلة ، لكن جسر Hue يتعامل مع الأضواء بشكل مختلف (لقد لاحظت أنه في وقت ما تنطفئ الأضواء عن المزامنة لجزء من الثانية عند الاتصال بـ Hue - لم يحدث أبدًا مع Trådfri ).

يتعامل جسر Hue مع الأضواء بشكل مختلف (لقد لاحظت أنه في وقت ما تنطفئ الأضواء عن المزامنة لجزء من الثانية عند الاتصال بـ Hue - لم يحدث أبدًا مع Trådfri).

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

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

عند التحكم في الأضواء المتصلة بجسر Hue مباشرة من محولات أو مستشعرات لاسلكية (Trådfri) ، سترى تأخيرًا لأن جسر Hue لا يقوم بإعداد تقارير السمات على الأضواء. كلما زاد عدد الأضواء في شبكتك ، زاد التأخير ، حيث يمر الاقتراع عبر المزيد من الأضواء.

عند توصيل مصابيح Hue بمحور Trådfri ، والتحكم في تلك الأضواء مباشرة من المحولات أو المستشعرات اللاسلكية (Trådfri) ، لن يتم تحديث حالة المحور أبدًا ، لأن مصابيح Hue لا تقوم بالإبلاغ عن السمات ولا يقوم مركز Trådfri بإجراء الاقتراع.

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

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

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

نفس المشكلة مع أضواء Tradfri التي تم إقرانها الآن بجسر Hue؟

ebaauw هل يجب أن تظهر مشكلة التوجيه عند توصيل ضوء بالجسر مباشرة وعبر جهاز توجيه ، أو فقط عندما لا يكون متصلاً بالجسر مباشرةً؟

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

نفس المشكلة مع أضواء Tradfri التي تم إقرانها الآن بجسر Hue؟

لدي فقط 3 لمبات مقترنة. لكن لا توجد قضايا لاحظتها.

ebaauw هل يجب أن تظهر مشكلة التوجيه عند توصيل ضوء بالجسر مباشرة وعبر جهاز توجيه ، أو فقط عندما لا يكون متصلاً بالجسر مباشرةً؟

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

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

هل يجب أن تظهر مشكلة التوجيه عند توصيل ضوء بالجسر مباشرة وعبر جهاز توجيه ، أو فقط عندما لا يكون متصلاً بالجسر مباشرةً؟

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

عندما يحتاج جهاز التوجيه إلى إرسال رسالة إلى جهاز غير موجود في جدول الجوار ، فإنه يرسل الطلب إلى جهاز توجيه مجاور ، حتى يتمكن من إعادة توجيهه. يتم إعادة إرسال الرسالة الفردية على مستوى NWK عبر قفزات متعددة على مستوى MAC. RaspBee / ConBee (في هذا المنظور) هو مجرد جهاز توجيه آخر. يرسل Afaik وهو جهاز طرفي الرسائل فقط إلى جهاز التوجيه الأصلي الخاص به.

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

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

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

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

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

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

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

مرة أخرى ، أخشى أن تفقد التفاصيل عندي ، لكن يمكنني التفكير في عدة سيناريوهات من شأنها أن تسبب هذا السلوك. يريد RaspBee / ConBee إرسال رسالة إلى العقدة 2 أو العقدة 1 ، ولا يتلقى ack ، ويخلص إلى أن العقدة 2 لا يمكن الوصول إليها ويزيلها من جدول الجوار. يحتوي الجدول الآن على مساحة لإدخال جديد ، والذي يتم استخدامه للعقدة 1.

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

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

يبدو هذا بالنسبة لي وكأن نهج منصة ZigBee متعددة البائعين محكوم عليه بالفشل

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

لقد استبدلت مصابيحي OSRAM و Trådfri و innr (التي كانت تسبب مشاكل) بمصابيح Hue. لدي الآن 104 عقدة و 51 جهاز توجيه و 53 جهازًا طرفيًا. 2/3 من أجهزة التوجيه هي مصابيح Hue. جهاز التوجيه الوحيد الذي يتعذر الوصول إليه (ولكن لا يزال يرسل التقارير) هو جهاز التحكم الستار Xiaomi. 20 من الأجهزة النهائية هي Hue و 20 Xiaomi و 8 Eurotronic Spirit و 5 IKEA. يتسبب كل من Eurotronic Spirit و IKEA Fyrtur في حدوث مشكلات لي بشكل منتظم (تم طردهما من قبل والدهما ، لكنهما لا يجدون والدًا جديدًا - لا يمكن الوصول إليه مرة أخرى من خلال البوابة ، ولكن لا يزالان يرسلان التقارير) ، يبدو الآخرون بخير. بالنسبة لجميع الأجهزة ، عادةً ما يعالج تدوير الطاقة الموقف ، لكن في بعض الأحيان أحتاج إلى فتح الشبكة عند إعادة تدوير الجهاز.

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

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

فكرة أخرى: نظرًا لأننا نعرف الرقائق التي تستخدمها ايكيا (Silabs EFR32 ، محرك الوزغة) ونعلم (من مصادر مختلفة على الشبكة) أنهم يستخدمون محرك zigbee الذي توفره Silabs ، يمكننا التفكير في إجراءين.

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

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

2 سنتي (أشعر بالإحباط بسبب فقدان الاتصالات في بعض الأحيان).

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

نحن لا. يجب أن يتم تنفيذه في البرامج الثابتة RaspBee / ConBee ، على ما أعتقد. ليست فكرة سيئة imho ، لكن ليس لدي أدنى فكرة عن مدى إمكانية ذلك ، نظرًا لقيود الحجم في الجهاز EEPROM و NVRAM. manup ، ما رأيك في هذا؟

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

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

نحن لا. يجب أن يتم تنفيذه في البرامج الثابتة RaspBee / ConBee ، على ما أعتقد. ليست فكرة سيئة imho ، لكن ليس لدي أدنى فكرة عن مدى إمكانية ذلك ، نظرًا لقيود الحجم في الجهاز EEPROM و NVRAM. manup ، ما رأيك في هذا؟

أعتقد أنني أعتبر manup جزءًا من نحن ؛)

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

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

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

نحن لا. يجب أن يتم تنفيذه في البرامج الثابتة RaspBee / ConBee ، على ما أعتقد. ليست فكرة سيئة imho ، لكن ليس لدي أدنى فكرة عن مدى إمكانية ذلك ، نظرًا لقيود الحجم في الجهاز EEPROM و NVRAM. manup ، ما رأيك في هذا؟

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

قد يكون المسار الإضافي نهجًا أكثر عمومية للتحكم في جداول التوجيه لجميع الأجهزة.

ملاحظة: يمكنك الاستعلام عن جدول توجيه جهاز توجيه عن طريق تحديده والضغط على مفتاح R ، وستظهر مسارات المرحلة التالية باللون الأزرق.

في الوقت الحالي ، عندما يتم فتح شبكة Zigbee ، يُسمح لجميع أجهزة التوجيه بأن تكون عقدة رئيسية حيث يتم إرسال Mgmt_Permit_Joining_req كبث. ومع ذلك ، إذا أرسلنا هذا الطلب على أنه إرسال أحادي فقط إلى جهاز توجيه معين ، فلا يمكن لجهاز جديد الانضمام إلا من خلال هذا الجهاز الواحد. قد يكون هذا مفيدًا لأجهزة Xiaomi التي غالبًا ما تلتزم بوالديها. بالنسبة للأجهزة المنضمة الأخرى مثل أجهزة التوجيه وعلى سبيل المثال الأجهزة الطرفية من Philips Hue ، لن يساعد ذلك كثيرًا نظرًا لأنها حرة في تحديد الآباء والطرق الجديدة بأنفسهم.

تبدو (الجديدة) Mgmt_NWK_IEEE_Joining_List_req في مواصفات Zigbee R22 مثيرة للاهتمام أيضًا:

يتم توفير الأمر Mgmt_NWK_IEEE_Joining_List_req كآلية للحصول على قائمة عناوين IEEE المتوقع انضمامها إلى الشبكة. يسمح هذا لجهاز التوجيه المحلي بتصفية طلبات الإشارة المحسنة والاستجابة فقط للأجهزة المنضمة.

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

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

ملاحظة: يمكنك الاستعلام عن جدول توجيه جهاز توجيه عن طريق تحديده والضغط على مفتاح R ، وستظهر مسارات المرحلة التالية باللون الأزرق.

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

هل جدول التوجيه مختلف عن جدول الجوار؟ الاستنشاق ، أرى فقط رسائل ZDP _Link Quality Request_ و _Link Quality Response_ ، والإبلاغ عن جدول الجوار. هل هذا يعني أن الخطوط إلى العقدة التي لم يتم تلوينها باللون الأزرق هي مسارات "واردة"؟

manup ، في الواقع تصور مثير للاهتمام

قد تكون الرصاصة الفضية تستخدم توجيه المصدر

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

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

ملاحظة: يمكنك الاستعلام عن جدول توجيه جهاز توجيه عن طريق تحديده والضغط على مفتاح R ، وستظهر مسارات المرحلة التالية باللون الأزرق.

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

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

رائع ، لم أكن أعرف ذلك. هل هناك نظرة عامة على جميع المفاتيح / الأوامر التي تدعمها واجهة المستخدم الرسومية؟

طلب واصف العقدة = 1
طلب واصف القوة = 2
طلب عنوان Nwk = 0
طلب جدول التوجيه = R
طلب إجازة Mgmt = L (مع إعادة الانضمام ، لا تستخدم مع أضواء innr!)
طلب نقاط النهاية النشطة = 7
طلب واصفات بسيطة = 8
التحديث = F5 / Cmd-R
حذف = Delete / Backspace
جهاز البوابة Annce = A (غير مفيد)

هل من الممكن إرجاع الخطوط الزرقاء قبل الاستعلام عن العقدة التالية؟

ليس بعد ، لقد كانت مجرد إضافة سريعة وقذرة لمشاهدة المسارات :)
ربما تكون إضافة مفتاح آخر مثل Shift-R لمسح مسارات العقدة مفيدة؟

لا يبدو أنها تعمل مع RaspBee / ConBee نفسها؟

لسوء الحظ ، لا يدعم RaspBee I / ConBee I أمر ZDP ذي الصلة ، فهو يعمل مع ConBee II.

هل جدول التوجيه مختلف عن جدول الجوار؟ الاستنشاق ، أرى فقط رسائل طلب جودة ارتباط ZDP ورسائل استجابة جودة الارتباط ، والإبلاغ عن جدول الجوار.

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

بالنسبة للعقد الموجودة في جدول الجوار (والتي تحتوي على إشارة قوية) ، لا يلزم اكتشاف المسار. يتم إنشاء جدول الجوار نفسه في الغالب باستخدام أوامر 1-hop NWK Link Status.

هل هذا يعني أن الخطوط إلى العقدة التي لم يتم تلوينها باللون الأزرق هي مسارات "واردة"؟

تمثل الخطوط غير الزرقاء (الأخضر / البرتقالي / الأصفر) فقط جدول الجوار 1-القفزة. الخطوط الزرقاء هي مسارات خارجية إلى بعض الوجهات وتمثل الخطوة التالية فقط (وليس المسار الكامل) في العرض الحالي ، لا يظهر عنوان NWK للوجهة ، ولكن من المحتمل أن تكون هناك مطبوعات تصحيح.

نحن لا. يجب أن يتم تنفيذه في البرامج الثابتة RaspBee / ConBee ، على ما أعتقد. ليست فكرة سيئة imho ، لكن ليس لدي أدنى فكرة عن مدى إمكانية ذلك ، نظرًا لقيود الحجم في الجهاز EEPROM و NVRAM. manup ، ما رأيك في هذا؟

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

قد يكون المسار الإضافي نهجًا أكثر عمومية للتحكم في جداول التوجيه لجميع الأجهزة.

ملاحظة: يمكنك الاستعلام عن جدول توجيه جهاز توجيه عن طريق تحديده والضغط على مفتاح R ، وستظهر مسارات المرحلة التالية باللون الأزرق.

وظيفة مفيدة حقا! بالأمس قمت بتشغيل لمبة TRÅDFRI GU10 WS 400lm (7 لمبات) مع البرنامج الثابت 2.0.022. عادت المشكلات اليوم ، وظهرت على لمبة TRÅDFRI E27 CWS opal 600lm مع البرامج الثابتة 1.3.009. بفضل هذه الوظيفة ، استطعت أن أرى أن لمبة E27 قد تم توجيهها عبر GU10. لقد قمت بإيقاف تشغيل كل GU10 ومثل السحر ، بدأت E27 في العمل مرة أخرى.

لذلك أصبح من الواضح تمامًا أن التوجيه عبر Innr و IKEA يسببان مشكلات. لقد بدأت في نقل مصابيح Innr och IKEA إلى بوابة hue الخاصة بي. يبدو أن مصابيح Philips هي أجهزة توجيه جيدة ولا تسبب مشكلات.

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

ضوء IKEA مدرج على أنه لا يمكن الوصول إليه ، لكنه لا يزال يستجيب لأوامر المجموعة. أيضًا نظرًا لأنه لا يزال معروفًا من قبل العديد من أجهزة التوجيه الأخرى ، يبدو أنهم أبلغوا عن رؤية الضوء (إنه 0x000B57FFFEC52C7D ):

11:49:33:392 ZDP Mgmt_Lqi_rsp zdpSeq: 190 from 0x000B57FFFE9BEBC3 total: 11, startIndex: 6, listCount: 3
11:49:33:392     * neighbor: 0x00158D00017028B0 (0xA3F5), LQI: 71, relation: 0x02 rxOnWHenIdle: 1
11:49:33:392     * neighbor: 0x90FD9FFFFE054F81 (0xC7BC), LQI: 41, relation: 0x02 rxOnWHenIdle: 1
11:49:33:393     * neighbor: 0x000B57FFFEC52C7D (0xD338), LQI: 69, relation: 0x02 rxOnWHenIdle: 1

و

11:49:50:017 Node 0x000B57FFFEC52C7D is known by 7 neighbors, last seen 33 s

في بعض الأحيان ، يبدو أن التواصل ممكن:

11:49:44:901 read attributes of 0x000B57FFFEC52C7D cluster: 0x0006: [ 11:49:44:902 0x0000 11:49:44:902 ]
11:49:44:902 add task 6636 type 19 to 0x000B57FFFEC52C7D cluster 0x0006 req.id 213
11:49:44:902 Poll APS request 213 to 0x000B57FFFEC52C7D cluster: 0x0006
11:49:44:904 Idle timer triggered
11:49:44:951 Poll APS confirm 213 status: 0x00
11:49:44:951 Erase task req-id: 213, type: 19 zcl seqno: 89 send time 0, profileId: 0x0104, clusterId: 0x0006

أحيانا لا:

12:18:51:033 read attributes of 0x000B57FFFEC52C7D cluster: 0x0006: [ 12:18:51:033 0x0000 12:18:51:033 ]
12:18:51:033 add task 4658 type 19 to 0x000B57FFFEC52C7D cluster 0x0006 req.id 119
12:18:51:033 Poll APS request 119 to 0x000B57FFFEC52C7D cluster: 0x0006
---
12:19:02:077 Poll APS confirm 119 status: 0xA7
12:19:02:077     drop item attr/modelid
12:19:02:077     drop item attr/swversion
12:19:02:077     drop item state/bri
12:19:02:077 0x000B57FFFEC52C7D error APSDE-DATA.confirm: 0xA7 on task

هناك القليل من المعلومات حول الخطأ الذي يحدث. ماذا تعني حالة 0xA7 ..؟

أي معلومات إضافية قد تساعد في معرفة ما يحدث؟

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

ضوء IKEA مدرج على أنه لا يمكن الوصول إليه ، لكنه لا يزال يستجيب لأوامر المجموعة. أيضًا نظرًا لأنه لا يزال معروفًا من قبل العديد من أجهزة التوجيه الأخرى ، يبدو أنهم أبلغوا عن رؤية الضوء (إنه 0x000B57FFFEC52C7D ):

11:49:33:392 ZDP Mgmt_Lqi_rsp zdpSeq: 190 from 0x000B57FFFE9BEBC3 total: 11, startIndex: 6, listCount: 3
11:49:33:392     * neighbor: 0x00158D00017028B0 (0xA3F5), LQI: 71, relation: 0x02 rxOnWHenIdle: 1
11:49:33:392     * neighbor: 0x90FD9FFFFE054F81 (0xC7BC), LQI: 41, relation: 0x02 rxOnWHenIdle: 1
11:49:33:393     * neighbor: 0x000B57FFFEC52C7D (0xD338), LQI: 69, relation: 0x02 rxOnWHenIdle: 1

و

11:49:50:017 Node 0x000B57FFFEC52C7D is known by 7 neighbors, last seen 33 s

في بعض الأحيان ، يبدو أن التواصل ممكن:

11:49:44:901 read attributes of 0x000B57FFFEC52C7D cluster: 0x0006: [ 11:49:44:902 0x0000 11:49:44:902 ]
11:49:44:902 add task 6636 type 19 to 0x000B57FFFEC52C7D cluster 0x0006 req.id 213
11:49:44:902 Poll APS request 213 to 0x000B57FFFEC52C7D cluster: 0x0006
11:49:44:904 Idle timer triggered
11:49:44:951 Poll APS confirm 213 status: 0x00
11:49:44:951 Erase task req-id: 213, type: 19 zcl seqno: 89 send time 0, profileId: 0x0104, clusterId: 0x0006

أحيانا لا:

12:18:51:033 read attributes of 0x000B57FFFEC52C7D cluster: 0x0006: [ 12:18:51:033 0x0000 12:18:51:033 ]
12:18:51:033 add task 4658 type 19 to 0x000B57FFFEC52C7D cluster 0x0006 req.id 119
12:18:51:033 Poll APS request 119 to 0x000B57FFFEC52C7D cluster: 0x0006
---
12:19:02:077 Poll APS confirm 119 status: 0xA7
12:19:02:077     drop item attr/modelid
12:19:02:077     drop item attr/swversion
12:19:02:077     drop item state/bri
12:19:02:077 0x000B57FFFEC52C7D error APSDE-DATA.confirm: 0xA7 on task

هناك القليل من المعلومات حول الخطأ الذي يحدث. ماذا تعني حالة 0xA7 ..؟

أي معلومات إضافية قد تساعد في معرفة ما يحدث؟

هذا يبدو وكأنه تكرار دقيق لمشاكلي!

ماذا تعني حالة 0xA7 ..؟

انظر هنا: https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Zigbee-Error-Codes-in-the-Log

تدوير الضوء

12:39:21:833 ZDP device announce: 0x000B57FFFEC52C7D, 0xD338, 0x8E
12:39:21:833 ZDP add fast discover for 0x000b57fffec52c7d
12:39:21:838 DeviceAnnce of LightNode: 0x000b57fffec52c7d Permit Join: 0
12:39:22:040 ZDP finished fast discover for 0x000b57fffec52c7d

ويبدو أنه يسعد بالإبلاغ عن حالته

12:39:22:665 read attributes of 0x000B57FFFEC52C7D cluster: 0x0006: [ 12:39:22:665 0x0000 12:39:22:665 ]
12:39:22:665 add task 10024 type 19 to 0x000B57FFFEC52C7D cluster 0x0006 req.id 175
12:39:22:665 Poll APS request 175 to 0x000B57FFFEC52C7D cluster: 0x0006
12:39:22:753 Poll APS confirm 175 status: 0x00
12:39:22:753 Erase task req-id: 175, type: 19 zcl seqno: 167 send time 0, profileId: 0x0104, clusterId: 0x0006
12:39:22:920 Node 0x000B57FFFEC52C7D is known by 9 neighbors, last seen 1 s

ثم:

12:39:26:760 ZDP active ep request to 0x000b57fffec52c7d
12:39:26:760 ZDP send request id: 0x07 to 0x000b57fffec52c7d
---
12:39:32:520 node 0000B57FFFEC52C7D leave wait state
12:39:32:521 ZDP active ep request to 0x000b57fffec52c7d
12:39:32:521 Incr. ZDP retry count 2 on item 7
---
12:39:44:655 add task 10125 type 21 to 0x000B57FFFEC52C7D cluster 0x0004 req.id 60
12:39:44:700 Erase task req-id: 60, type: 21 zcl seqno: 171 send time 0, profileId: 0x0104, clusterId: 0x0004
---
12:39:45:405 create binding for attribute reporting of cluster 0x0000
12:39:45:405 queue binding task for 0x000B57FFFEC52C7D, cluster 0x0000
12:39:45:405 create binding for attribute reporting of cluster 0x0006
12:39:45:405 queue binding task for 0x000B57FFFEC52C7D, cluster 0x0006
12:39:45:405 create binding for attribute reporting of cluster 0x0008
12:39:45:405 queue binding task for 0x000B57FFFEC52C7D, cluster 0x0008
12:39:45:405 Force binding of attribute reporting for node HK houtlamp 2
---
12:39:50:760 Node 0x000B57FFFEC52C7D is known by 9 neighbors, last seen 28 s
---
12:40:06:904 binding/unbinding timeout srcAddr: B57FFFEC52C7D, retry
12:40:08:905 binding/unbinding timeout srcAddr: B57FFFEC52C7D, retry
---
12:40:11:881 read attributes of 0x000B57FFFEC52C7D cluster: 0x0006: [ 12:40:11:881 0x0000 12:40:11:881 ]
12:40:11:882 add task 10241 type 19 to 0x000B57FFFEC52C7D cluster 0x0006 req.id 205
12:40:11:882 Poll APS request 205 to 0x000B57FFFEC52C7D cluster: 0x0006
---
12:40:21:640 ZDP skip fetch, node 0xB57FFFEC52C7D has unconfirmed requests [1]
---
12:40:22:957 Poll APS confirm 205 status: 0xA7
12:40:22:957     drop item attr/modelid
12:40:22:957     drop item attr/swversion
12:40:22:957     drop item state/bri
12:40:22:957 0x000B57FFFEC52C7D error APSDE-DATA.confirm: 0xA7 on task
12:40:22:957 Erase task req-id: 205, type: 19 zcl seqno: 175 send time 11, profileId: 0x0104, clusterId: 0x0006
12:40:22:957 max transmit errors for node 0x000B57FFFEC52C7D, last seen by neighbors 78 s
---
12:40:28:904 giveup binding srcAddr: B57FFFEC52C7D
---
12:40:30:904 binding/unbinding timeout srcAddr: B57FFFEC52C7D, retry
---
12:40:32:050 giveup binding srcAddr: B57FFFEC52C7D
---
12:40:33:568 ZDP skip fetch, node 0xB57FFFEC52C7D has unconfirmed requests [1]
---
12:40:39:481 ZDP skip fetch, node 0xB57FFFEC52C7D has unconfirmed requests [1]
---
12:40:42:987 max transmit errors for node 0x000B57FFFEC52C7D, last seen by neighbors 10 s
---
12:40:43:276 read attributes of 0x000B57FFFEC52C7D cluster: 0x0006: [ 12:40:43:276 0x0000 12:40:43:276 ]
12:40:43:277 add task 10380 type 19 to 0x000B57FFFEC52C7D cluster 0x0006 req.id 157
12:40:43:277 Poll APS request 157 to 0x000B57FFFEC52C7D cluster: 0x0006
---
12:40:54:621 Poll APS confirm 157 status: 0xA7
12:40:54:621     drop item attr/modelid
12:40:54:621     drop item attr/swversion
12:40:54:621     drop item state/bri
12:40:54:621 0x000B57FFFEC52C7D error APSDE-DATA.confirm: 0xA7 on task
12:40:54:621 Erase task req-id: 157, type: 19 zcl seqno: 180 send time 12, profileId: 0x0104, clusterId: 0x0006
12:40:54:621 max transmit errors for node 0x000B57FFFEC52C7D, last seen by neighbors 22 s

توقف عن العمل. حتى .. بعد دقيقتين

12:42:10:529 LightNode removed 0x000b57fffec52c7d
12:42:10:530 Node zombie state changed 0x000b57fffec52c7d
---
12:42:39:361 Node 0x000B57FFFEC52C7D is known by 0 neighbors, last seen 0 s
---
12:43:06:904 add task 11002 type 21 to 0x000B57FFFEC52C7D cluster 0x0004 req.id 83
12:43:06:953 Erase task req-id: 83, type: 21 zcl seqno: 198 send time 0, profileId: 0x0104, clusterId: 0x0004
12:43:07:329 Node 0x000B57FFFEC52C7D is known by 0 neighbors, last seen 22 s
---
12:43:12:455 read attributes of 0x000B57FFFEC52C7D cluster: 0x0006: [ 12:43:12:455 0x0000 12:43:12:455 ]
12:43:12:455 add task 11026 type 19 to 0x000B57FFFEC52C7D cluster 0x0006 req.id 125
12:43:12:455 Poll APS request 125 to 0x000B57FFFEC52C7D cluster: 0x0006
12:43:12:498 ZDP status = 0x00 -> SUCCESS

أعتقد أنني بحاجة إلى الحصول على شم زيجبي لمعرفة ما يحدث عبر الهواء.

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

ماذا تعني حالة 0xA7 ..؟

انظر هنا: https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Zigbee-Error-Codes-in-the-Log

شكرا على ذلك! بطريقة ما هذا ما كنت أتوقعه ...

حاولت إقران لمبة TRÅDFRI GU10 WS 400lm (7 لمبات) بجسر Philips Hue. أصبحت العديد من المصابيح الأخرى على الشبكة غير متوفرة وكان لمصباح TRÅDFRI GU10 WS 400lm نفس السلوك كما هو الحال مع Deconz ، والاستجابة لأمر المجموعة ولكن لا يوجد استجابة على الإرسال الأحادي.

يبدو أن لمبة TRÅDFRI GU10 WS 400lm بها مشكلة ما. سأقوم ببعض الاختبارات إذا كانت المصابيح الصناعية أو كلها لا تعمل.

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

MikaelHoogen ، أي إصدار من المصابيح والبرامج الثابتة لديك؟

لقد رأيت هذه المشكلة على v1 E27 WS 980lm و GU10 WS 400lm و E27 CWS 600lm و E15 WS وجميع لوحات FLOALT الثلاثة على بوابات Ikea و HUE و DeCONZ خلال العام ونصف العام الماضي.
أنا مقتنع أن هذه مشكلة تتعلق بالنفايات الخطرة. إنه عشوائي تمامًا أي العقدة تموت.
هنا في النرويج ، جميع الأجهزة الإلكترونية تحت الضمان لمدة عامين. سيحاول فتح تذكرة وسماع ما يقولون.
بخصوص FLOALT. قبل بضعة أشهر ، كانت إيكيا تجري بيع تخليص لهم. ربما كان ذلك للتخلص من كل v1؟
هل رأى أي شخص FLOALT v2 هناك؟ (مع برنامج التشغيل sy5882 ربما؟)

لقد رأيت هذه المشكلة على v1 E27 WS 980lm و GU10 WS 400lm و E27 CWS 600lm و E15 WS وجميع لوحات FLOALT الثلاثة على بوابات Ikea و HUE و DeCONZ خلال العام ونصف العام الماضي.
أنا مقتنع أن هذه مشكلة تتعلق بالنفايات الخطرة. إنه عشوائي تمامًا أي العقدة تموت.
هنا في النرويج ، جميع الأجهزة الإلكترونية تحت الضمان لمدة عامين. سيحاول فتح تذكرة وسماع ما يقولون.
بخصوص FLOALT. قبل بضعة أشهر ، كانت إيكيا تجري بيع تخليص لهم. ربما كان ذلك للتخلص من كل v1؟
هل رأى أي شخص FLOALT v2 هناك؟ (مع برنامج التشغيل sy5882 ربما؟)

هذا أيضًا ما كنت أحاول قوله منذ بعض الوقت. لدي مشاكل فقط مع مصابيح Trådfri v1. يساعد جسر Philips Hue ولكن العقد لا تزال غير قابلة للوصول من وقت لآخر.

قبل يومين قررت استبدال جميع لمبة IKEA GU10 الـ 12 بالإصدار الجديد (أبيض دافئ).
هذا جعل هذه القضية أسوأ. الآن أفقد أيضًا أجواء Hue GU10 البيضاء ولون Hue E14.

أستخدم ضوء deConz و IKEA منذ البداية عندما خرجوا. لدي حوالي 70 عقدة في شبكتي. معظمهم من أضواء ايكيا. لدي أيضًا عدد قليل من Philips Hue (4 أضواء) وواحد من Osram. المستشعرات لدي القليل من حركة Ikea والعديد من مستشعرات الحركة Xiaomi.

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

أستخدم ضوء deConz و IKEA منذ البداية عندما خرجوا. لدي حوالي 70 عقدة في شبكتي. معظمهم من أضواء ايكيا. لدي أيضًا عدد قليل من Philips Hue (4 أضواء) وواحد من Osram. المستشعرات لدي القليل من حركة Ikea والعديد من مستشعرات الحركة Xiaomi.

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

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

يواجه العديد من المستخدمين مشكلات مماثلة حتى مع مركز ايكيا. لذلك أعتقد أن هذه ليست مشكلة فريدة تتعلق بـ deconz. ومع ذلك ، إذا استطاع شخص ما إصلاح هذا ، "تصحيحه / العثور على حل بديل" سيكون الرجال هنا! <3

لدي نفس المشكلة تمامًا مع العائلة ومع الإعداد.

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

إصدار Deconz 2.05.69
البرامج الثابتة Conbee II 264A0700

إنها ليست مثالية بنسبة 100٪ ، والمصابيح التي لاحظتها هي مصابيح E27 Ikea (Rev1).
عندما حصلت على مصابيح Ikea هذه مع جسر Philips Hue الخاص بي ، كانت صلبة جدًا ، لذا ربما أعود بها إلى Hue وأحتفظ بشبكة Zigbee هذه CC2531 (البرامج الثابتة لجهاز التوجيه) وأجهزة استشعار Xiaomi.
لدي أيضًا مصباح Innr (E14) و SP120 ، لكنهما لا يزالان على ما يرام مع Deconz.

أنا أستخدم Home Assistant و Deconz للتحكم في حوالي 20 مصباحًا من Ikea (ومجموعة من أجهزة الاستشعار الأخرى). المصابيح هي في الأساس GU10s والتي تم تجميعها في 3 نقاط لضوء واحد

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

قبل بضعة أسابيع ، قمت بإنشاء مجموعات لأضواءي في Phoscon ، وبدأت في الإشارة إلى هذه المجموعات في HASS.

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

بالنسبة لي ، هذا يبدو وكأنه مشكلة في Deconz API وربما التعامل مع لمبات متعددة في تتابع سريع عليها.

لدي أيضًا مشكلات مع أجهزة Ikea (المصابيح ومؤخرًا أيضًا جهاز التحكم عن بعد Symfonisk) التي أصبحت غير متوفرة وتتطلب إعادة الاقتران مع deCONZ. لقد فتى هذه القضايا لمدة 6 أشهر أو حتى أعتقد. ليس هناك الكثير لإضافة أكثر مما أعتقد أنه يحدث بشكل متكرر في الآونة الأخيرة. ليس لدي أي لمبات GU10 فقط مختلف E27 و E14 (وأجهزة تحكم عن بعد مختلفة). يبدو أن بعض الأجهزة أكثر عرضة للتسرب (ربما اعتمادًا على كيفية تشابكها أو تشابهها). لدي حوالي 20 جهازًا بحد أقصى 5 أمتار من Conbee I مع أحدث FW / Phoscon / deCONZ.

لدي أيضًا مشكلات مع أجهزة Ikea (المصابيح ومؤخرًا أيضًا جهاز التحكم عن بعد Symfonisk) التي أصبحت غير متوفرة وتتطلب إعادة الاقتران مع deCONZ. لقد فتى هذه القضايا لمدة 6 أشهر أو حتى أعتقد. ليس هناك الكثير لإضافة أكثر مما أعتقد أنه يحدث بشكل متكرر في الآونة الأخيرة. ليس لدي أي لمبات GU10 فقط مختلف E27 و E14 (وأجهزة تحكم عن بعد مختلفة). يبدو أن بعض الأجهزة أكثر عرضة للتسرب (ربما اعتمادًا على كيفية تشابكها أو تشابهها). لدي حوالي 20 جهازًا بحد أقصى 5 أمتار من Conbee I مع أحدث FW / Phoscon / deCONZ.

جرب Deconz الإصدار 2.05.69. مستقرة جدًا بالنسبة لي مع Ikea و Innr و Xiaomi

لدي مشكلة وتذكرة مماثلة مفتوحة https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2256#issue -543476970

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

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

لدي أيضًا مشكلات مع أجهزة Ikea (المصابيح ومؤخرًا أيضًا جهاز التحكم عن بعد Symfonisk) التي أصبحت غير متوفرة وتتطلب إعادة الاقتران مع deCONZ. لقد فتى هذه القضايا لمدة 6 أشهر أو حتى أعتقد. ليس هناك الكثير لإضافة أكثر مما أعتقد أنه يحدث بشكل متكرر في الآونة الأخيرة. ليس لدي أي لمبات GU10 فقط مختلف E27 و E14 (وأجهزة تحكم عن بعد مختلفة). يبدو أن بعض الأجهزة أكثر عرضة للتسرب (ربما اعتمادًا على كيفية تشابكها أو تشابهها). لدي حوالي 20 جهازًا بحد أقصى 5 أمتار من Conbee I مع أحدث FW / Phoscon / deCONZ.

جرب Deconz الإصدار 2.05.69. مستقرة جدًا بالنسبة لي مع Ikea و Innr و Xiaomi

سأحاول ذلك بالإضافة إلى

قبل بضعة أسابيع ، قمت بإنشاء مجموعات لأضواءي في Phoscon ، وبدأت في الإشارة إلى هذه المجموعات في HASS.

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

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

انظر السجل أدناه. هل يبدو هذا سلوك "طبيعي"؟ كلا الأضواء المتورطة هي أطوال Ikea. يرسل DeConz طلبًا إلى "المرآب" ، ويوجهه عبر "Zolder". ثم يحاول "Zolder" نقله إلى "Garage" ، ولكن يبدو أن ذلك فشل (لماذا؟) وأعيد المحاولة 20 مرة بتتابع سريع جدًا (معظمها في غضون 3 مللي ثانية). أخيرًا ، يستسلم "Zolder" ويرسل فشل الارتباط مرة أخرى إلى DeConz.

هل يجب أن يكون هذا عدوانيًا في إعادة محاولة الإرسال؟

أيضًا: لاحظت أن DeConz يستمر في إرسال الطلبات إلى Garage عبر Zolder بسعادة ، على الرغم من فشل الرابط بشكل واضح. يقوم DeConz بهذا حتى عندما لا يكون Garage في تقرير حالة الارتباط لـ Zolder بعد الآن. أيضًا إذا كان Garage في بعض الأحيان موجودًا في تقرير حالة الارتباط الخاص بـ Zolder ، فسيكون ذلك بتكلفة 7 لكل من الوارد والصادر. في الواقع الطريق من Garage إلى DeConz ليس عبر Zolder ...
لماذا يستمر DeConz في التوجيه عبر Zolder حتى بعد ظهور رسالة فشل الارتباط؟

No.          Time         Source       Transmit Dev Receive Dev  Destination  Protocol     Info         
7580         748.356336   DeConz       DeConz       Zolder       Garage       ZigBee ZDP   Link Quality Request
7582         748.360218   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7583         748.363417   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7584         748.368857   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7585         748.373337   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7587         748.419739   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7588         748.424219   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7589         748.429019   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7590         748.434460   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7591         748.481181   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7592         748.485021   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7593         748.488541   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7594         748.492702   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7595         748.541983   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7596         748.545824   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7597         748.550944   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7598         748.556384   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7599         748.594786   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7600         748.597986   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7601         748.602787   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7602         748.608226   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7603         748.640867   Zolder       Zolder       DeConz       DeConz       ZigBee       Network Status, 0x9e0c: Non-tree Link Failure

حسنًا ، لقد أمضيت بعض الوقت في قراءة وثائق silabs ZigBee (تعتمد IKEA على رقائق silabs).
يبدو أن سلوك إعادة المحاولة هو تمامًا كما هو موضح في المستندات.

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

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

بعد ذلك عدت مرة أخرى وأعتقد أن لدي طرق سيئة مرة أخرى.

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

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

• يرسل DeConz حزمًا many-to-one route Route Request . والنتيجة هي أن أي جهاز سيقوم أولاً باكتشاف الطريق. من المفترض أن يغذي هذا المكثف (المنسق) بمعلومات حول كيفية الوصول إلى هذا الجهاز. يبدو أن DeConz يتجاهل هذه المعلومات لأنه يقوم بالتوجيه ...

No.         Time        Source      Tran Dev    Recv Dev    Destination Protocol    Info
7544        747.873     DeConz      DeConz      Zolder      Garage      ZigBee ZDP  Link Quality Request
7546        747.876     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7547        747.882     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7548        747.887     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7549        747.892     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7550        747.919     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7551        747.925     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7552        747.929     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7553        747.932     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7554        747.980     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7555        747.985     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7556        747.990     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7557        747.995     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7558        748.046     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7559        748.052     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7560        748.055     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7561        748.061     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7563        748.066     Garage      Garage      Kerstver    DeConz      ZigBee      Route Record, Dst: 0x0000
7565        748.076     Garage      Kerstver    HK zoutlamp DeConz      ZigBee      Route Record, Dst: 0x0000
7567        748.084     Garage      HK zoutlamp DeConz      DeConz      ZigBee      Route Record, Dst: 0x0000

تحتوي هذه الحزمة الأخيرة على معلومات حول كيفية الوصول إلى المرآب:

Command Frame: Route Record
    Command Identifier: Route Record (0x05)
    Relay Count: 2
    Relay Device 1: 0x731e[Kerstverli]
    Relay Device 2: 0xa3f5[HK zoutlam]

ولكن يتم إرسال الطلب التالي إلى المرآب مرة أخرى عبر Zolder

No.         Time        Source      Tran Dev    Recv Dev    Destination Protocol    Info
7569        748.112847  DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7570        748.117327  DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7573        748.126608  DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request

لن أتفاجأ من أن هذا السلوك له علاقة بسلوك ضوء ايكيا غير المستقر.

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

ملاحظة أخرى ... جهازي الترحيل في الحزمة أعلاه كلاهما Xiaomi Plugs. لا يتم الاستعلام عنهم أبدًا عن جودة الارتباط. لماذا ا؟
هل يمكن أن يكون DeConz يستخدم المعلومات الواردة في Link Quality Response لبناء جدول التوجيه الخاص به وبالتالي يتجاهل أجهزة التوجيه الصالحة تمامًا؟ مع جودة ارتباط جيدة ببعض مصابيح ايكيا غير السعيدة ...

هل ترى فقط هذا السلوك لأجهزة ايكيا أو سلوكًا عامًا لتجاهل المسار الأمثل؟ أعتقد أن لديك عددًا لائقًا من أجهزة ايكيا؟

لست متأكدًا ، سأحتاج إلى التحقق من ذلك. سؤال جيد.

لدي عدد كبير جدًا من مصابيح ايكيا ، نعم.

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

بالنظر إلى عدة طرق أخرى وأرى نفس السلوك.

أرى فقط أن أجهزة Xiaomi لا يتم الاستعلام عنها من أجل Link Quality ، فجميع العلامات التجارية الأخرى هي. أعتقد أن هذا نوع من القائمة السوداء ..؟

مثال على سلوك توجيه آخر:

من DeConz ، دائمًا:
DeConz --> WC Lamp --> Badkamer Ledstrip

غالبًا ما يتغير مسار العودة بعد طلب مسار متعدد إلى واحد. لاحظ أنه من وجهة نظر جغرافية ، كل هذا منطقي ...
Badkamer Ledstrip --> WC Lamp --> DeConz
Badkamer Ledstrip --> Gang 1 --> DeConz
Badkamer Ledstrip --> Zoldertrap Lamp --> DeConz
Badkamer Ledstrip --> Gang 1 --> Zoldertrap Lamp --> DeConz

بالنسبة إلى ضوء المرآب ، أرى من DeConz:
DeConz --> Zolder Noord Lamp --> Garage (طريق غير مستقر للغاية ..!)

طريق العودة أرى:
Garage --> Kerstverlichting --> On/Off Light 36 --> DeConz
Garage --> Kerstverlichting --> HK Zoutlamp --> DeConz

الآن عندما ألقي نظرة على الجدول في تقارير حالة الارتباط ، يكون المسار فوق المسارات من Garage إلى DeConz منطقيًا:
التكلفة الإجمالية Garage --> Kerstverlichting --> On/Off Light 36 --> DeConz : 4
التكلفة الإجمالية Garage --> Kerstverlichting --> HK Zoutlamp --> DeConz : 4

من DeConz إلى Garage لا يقوم بما يلي:
التكلفة الإجمالية DeConz --> Zolder Noord Lamp --> Garage أمريكية

manup ، هل يمكنك توضيح خوارزمية تكلفة المسار المستخدمة؟ لماذا ما ورد أعلاه منطقي؟

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

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

يمكنني أن أجد هذا في سجلات الاستنشاق. أحيانًا يكون مصباح Zolder قادرًا على التواصل مع Garage وأحيانًا لا. في أي وقت يتعذر على Zolder light الاتصال بـ Garage ، فإنه يبلغ عن هذا:

ZigBee Network Layer Command, Dst: DeConz, Src: Zolder No
    Frame Control Field: 0x1a09, Frame Type: Command, Discover Route: Suppress, Security, Destination, Extended Source Command
    Destination: 0x0000[DeConz]
    Source: 0xd6b7[Zolder Noo]
    Radius: 30
    Sequence Number: 65
    Destination: dresden-_ff:ff:00:c4:9a (00:21:2e:ff:ff:00:c4:9a)
    Extended Source: SiliconL_ff:fe:c3:4a:3e (00:0b:57:ff:fe:c3:4a:3e)
    ZigBee Security Header
    Command Frame: Network Status
        Command Identifier: Network Status (0x03)
        Status Code: Non-tree Link Failure (0x02)
        Destination: 0x9e0c[Garage]

يجب أن تخبر هذه الحزمة DeConz بالبدء في البحث عن طريق آخر للوصول إلى Garage ، لكن هذا لا يحدث. يتم توجيه الحزمة التالية المرسلة إلى Garage مرة أخرى عبر Zolder. بالنسبة لي هذا خطأ يجب حله.
يتم استلام الحزمة التالية من Garage بواسطة مصباح Zolder light ، لكن هذا الضوء لا يحاول حتى إرساله إلى المرآب. ربما يكون هذا سلوكًا لبرامج ايكيا الثابتة وهو ليس جيدًا ، لكن السبب الجذري للمشكلة هو رفض DeConz لإيجاد طريق بديل.
أعتقد أنه إذا لم يكن المسار متاحًا لفترة طويلة من الوقت ، فربما يكون ضوء المرآب متعطشًا لـ ACKs بمستوى أعلى من بروتوكول 802.15.4 وقد يتسبب ذلك في فصل البرنامج الثابت أو حتى تعطله. وأنا أوافق على أنه لا ينبغي ذلك ، لكن السبب الأساسي هو أن DeConz يرفض إيجاد طريق جديد إلى ضوء المرآب.

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

الشيء المضحك هو أنه في الوضع الجديد ، يتحدث DeConz الآن مباشرة مع Garage light ، ولا توجد أجهزة توجيه في المنتصف.
يتم الوصول إلى Zolder الآن من خلال مسار عبر جهازي توجيه آخرين (على الرغم من أنه كان من الواضح أنه يمكن الوصول إليه مباشرة بواسطة DeConz) ، لذلك يبدو لي أن بعض الجداول (جدول الجار؟) ممتلئة داخل البرامج الثابتة للتوجيه DeConz.

ربما هذا مرتبط برفضها خلق طريق جديد ردا على طريق فاشل ..؟

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

أود المساعدة في إيجاد حل لهذه المشكلات ، لأنها تزعجني. إذا منحت حق الوصول إلى الكود المصدري للبرنامج الثابت ، يمكنني المساهمة مباشرة (حتى لو لم يكن مفتوح المصدر). لا مانع من مساعدة Dresden Elektronik بهذه الطريقة :)

تم إنجاز عمل ممتاز! 💪🏼
نأمل أن نتمكن من جذب انتباه المطورين لإصلاح هذا الأمر. يبدو أن لديك إعدادًا وعملية جيدة ، لذا سيكون من الممكن التحقق من الإصلاح "بسهولة".
أفهم الآن السلوك الذي رأيته والذي أشرت إليه باسم "الشفاء الذاتي" ولماذا تعمل بعض المصابيح فجأة.

عمل جيدdjwlindenaar آمل @ manup أن ينظر إلى هذا.

manup أي تعليقات؟

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

ملاحظة أخرى ... جهازي الترحيل في الحزمة أعلاه كلاهما Xiaomi Plugs. لا يتم الاستعلام عنهم أبدًا عن جودة الارتباط. لماذا ا؟
هل يمكن أن يكون DeConz يستخدم المعلومات الواردة في Link Quality Response لبناء جدول التوجيه الخاص به وبالتالي يتجاهل أجهزة التوجيه الصالحة تمامًا؟ مع جودة ارتباط جيدة ببعض مصابيح ايكيا غير السعيدة ...

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

وبالتالي فإن المحرك الرئيسي للحد من طلبات معينة هو منع الأخطاء في البرامج الثابتة للجهاز وتقليد سلوك بوابة البائع ذات الصلة عن كثب ، يمكن العثور على بعض نتائج التحقيق في https://github.com/dresden-elektronik/deconz-rest -plugin / wiki / End-device-Polling

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

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

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

انظر السجل أدناه. هل يبدو هذا سلوك "طبيعي"؟ كلا الأضواء المتورطة هي أطوال Ikea. يرسل DeConz طلبًا إلى "المرآب" ، ويوجهه عبر "Zolder". ثم يحاول "Zolder" نقله إلى "Garage" ، ولكن يبدو أن ذلك فشل (لماذا؟) وأعيد المحاولة 20 مرة بتتابع سريع جدًا (معظمها في غضون 3 مللي ثانية). أخيرًا ، يستسلم "Zolder" ويرسل فشل الارتباط مرة أخرى إلى DeConz.

هل يجب أن يكون هذا عدوانيًا في إعادة محاولة الإرسال؟

أيضًا: لاحظت أن DeConz يستمر في إرسال الطلبات إلى Garage عبر Zolder بسعادة ، على الرغم من فشل الرابط بشكل واضح. يقوم DeConz بهذا حتى عندما لا يكون Garage في تقرير حالة الارتباط لـ Zolder بعد الآن. أيضًا إذا كان Garage في بعض الأحيان موجودًا في تقرير حالة الارتباط الخاص بـ Zolder ، فسيكون ذلك بتكلفة 7 لكل من الوارد والصادر. في الواقع الطريق من Garage إلى DeConz ليس عبر Zolder ...
لماذا يستمر DeConz في التوجيه عبر Zolder حتى بعد ظهور رسالة فشل الارتباط؟

No.          Time         Source       Transmit Dev Receive Dev  Destination  Protocol     Info         
7580         748.356336   DeConz       DeConz       Zolder       Garage       ZigBee ZDP   Link Quality Request
7582         748.360218   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7583         748.363417   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7584         748.368857   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7585         748.373337   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7587         748.419739   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7588         748.424219   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7589         748.429019   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7590         748.434460   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7591         748.481181   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7592         748.485021   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7593         748.488541   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7594         748.492702   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7595         748.541983   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7596         748.545824   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7597         748.550944   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7598         748.556384   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7599         748.594786   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7600         748.597986   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7601         748.602787   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7602         748.608226   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7603         748.640867   Zolder       Zolder       DeConz       DeConz       ZigBee       Network Status, 0x9e0c: Non-tree Link Failure

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

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

شكر.

في هذه الحالة ، لم يتم تلقي أي رسالة من ضوء Garage عبر Zolder. لذلك لا أتوقع أن تستمر DeConz في استخدام الطريق. انظر مشاركاتي الأخرى ...

رمز الحالة: فشل الارتباط غير الشجري (0x02)

يبدو أننا حصلنا على فائز ، لقد تحققت من مصدر مكدس Zigbee (R21 ، ConBee II) ويتم تجاهل رمز الحالة هذا تمامًا. : -O تحتاج إلى التحقق من مكدس AVR Zigbee أيضا ، من المحتمل أن نفس المشكلة هناك.

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

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

هذا هو القسم من مواصفات Zigbee حول ما يجب أن يحدث في هذه الحالة بالذات:

عند استلام إطار أمر حالة الشبكة بواسطة جهاز توجيه يمثل الوجهة المقصودة للأمر حيث يكون لحقل رمز الحالة لحمولة إطار الأمر قيمة 0x01 أو 0x02 التي تشير إلى فشل الارتباط ، ستزيل طبقة NWK إدخال جدول التوجيه المطابق لقيمة حقل عنوان الوجهة لحمولة إطار الأمر ، إن وجد ، وإبلاغ الطبقة الأعلى التالية بالفشل باستخدام إشارة NLME-NWK-STATUS باستخدام نفس رمز الحالة.

لذا يجب أن يعمل الإصلاح أعلاه هنا من أجل 0x02 ، كما لم يتم التعامل مع 0x01 وسأضيف ذلك أيضًا.

0x00 No Route Available  (already handled)
0x01 Tree Link Failure
0x02 Non Tree Link Failure

@ manup عظيم! لقد ذكرت Conbee II. هل سيعمل هذا الإصلاح أيضًا مع Conbee I؟

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

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

أغلقت هذه المشكلة بطريق الخطأ ... أعيد فتحها. رائع أننا نحرز تقدمًا في هذا الشأن.

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

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

لست متأكدًا من فهمي لسؤالك. ما الحزمة التي تبحث عنها؟ وإلى أي ضوء (جراج أم زولدر)؟

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

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

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

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

أنا على Raspbee راجع للشغل.

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

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

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

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

بفضل التنوب النظر في هذا ، في غاية الامتنان!

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

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

شكرا مانوب! سأقوم بالترقية إلى المهاجم الجديد ثانيًا متاحًا وتقديم التحديثات.

هل يمكن ربط هذه المشكلة أيضًا بمشكلة التحكم في ستائر Ikea Fyrtur؟

واحد آخر يبدو غريباً بالنسبة لي. manup ، هل يمكن أن تكون هذه مشكلة أيضًا؟

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

أتساءل عما إذا كان هناك خطأ في اختيار رقم التسلسل أو ربما يكون مسموحًا به (لا أعرف) وهذا السلوك يتسبب في حدوث خطأ في البرنامج الثابت Tradfri. يوجد طلب واحد برقم 215 وطلبان برقم 216. هل يمكن أن يكون لدينا نوع من حالة السباق حيث يتسبب التعامل مع الطلبات من قبل البرنامج الثابت tradfri في تسرب الذاكرة أو إنهاء المكالمة بسبب الطلبين بنفس الرقم في نفس الوقت تقريبًا؟ لدى Shoud DeConz طلبان بنفس رقم التسلسل؟

13:09:40:905 Force read attributes for node HK houtlamp
13:09:40:905 binding for cluster 0x0000 of 0x000B57FFFEDBFE18 exists (verified by reporting)
13:09:40:905 binding for cluster 0x0006 of 0x000B57FFFEDBFE18 exists (verified by reporting)
13:09:40:905 configure reporting rq seq 215 for 0x000B57FFFEDBFE18, attribute 0x0006/0x0000
13:09:40:906 binding for cluster 0x0008 of 0x000B57FFFEDBFE18 exists (verified by reporting)
13:09:40:906 configure reporting rq seq 216 for 0x000B57FFFEDBFE18, attribute 0x0008/0x0000
13:09:40:906 Force binding of attribute reporting for node HK houtlamp
13:09:40:908 add task 7435258 type 21 to 0x000B57FFFEDBFE18 cluster 0x0004 req.id 233
13:09:41:013 Erase task req-id: 233, type: 21 zcl seqno: 216 send time 0, profileId: 0x0104, clusterId: 0x0004
13:09:41:053 ZCL configure reporting rsp seq: 215 0x000B57FFFEDBFE18 for cluster 0x0006 attr 0x0000 status 0x00
13:09:41:077 ZCL configure reporting rsp seq: 216 0x000B57FFFEDBFE18 for cluster 0x0008 attr 0x0000 status 0x00
13:09:41:116 verified group capacity: 255 and group count: 2 of LightNode 0x000b57fffedbfe18
13:09:41:116 0x000b57fffedbfe18 found group 0x0001
13:09:41:116 0x000b57fffedbfe18 found group 0xFFF0

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

No.          Source       Transmit Dev Receive Dev  Destination  Protocol     Info
2196482      DeConz       HK zoutlamp  HK houtlamp  HK houtlamp  ZigBee HA    ZCL: Configure Reporting, Seq: 215
2196484      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       Route Record, Dst: 0x0000
2196486      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       Route Record, Dst: 0x0000
2196488      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       Route Record, Dst: 0x0000
2196490      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       Route Record, Dst: 0x0000
2196492      DeConz       DeConz       HK zoutlamp  HK houtlamp  ZigBee HA    ZCL Groups: Get Group Membership, Seq: 216
2196494      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee HA    ZCL: Configure Reporting Response, Seq: 215
2196496      DeConz       HK zoutlamp  HK houtlamp  HK houtlamp  ZigBee HA    ZCL Groups: Get Group Membership, Seq: 216
2196497      DeConz       DeConz       HK zoutlamp  HK houtlamp  ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196498      DeConz       DeConz       HK zoutlamp  HK houtlamp  ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196500      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196502      DeConz       HK zoutlamp  HK houtlamp  HK houtlamp  ZigBee HA    ZCL Groups: Get Group Membership, Seq: 216
2196504      DeConz       HK zoutlamp  HK houtlamp  HK houtlamp  ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196506      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       Route Record, Dst: 0x0000
2196508      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee HA    ZCL: Configure Reporting Response, Seq: 216
2196510      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196511      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196512      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196513      DeConz       DeConz       HK zoutlamp  HK houtlamp  ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196515      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196517      DeConz       HK zoutlamp  HK houtlamp  HK houtlamp  ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196519      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee HA    ZCL Groups: Get Group Membership Response, Seq: 216
2196521      DeConz       DeConz       HK zoutlamp  HK houtlamp  ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196523      DeConz       HK zoutlamp  HK houtlamp  HK houtlamp  ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1

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

إليك أول برنامج اختبار ثابت لـ ConBee II

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_R21_0x26520700.bin.GCF

سيتم الآن إعادة نقل هذا إلى البرامج الثابتة ConBee I / RaspBee ، عبر الإنترنت قريبًا.

وهنا الإصدار التجريبي لـ ConBee I و RaspBee مع إصلاح خطأ المسار.
آمل أن يجلب بعض التحسينات لاكتشاف طريق جديد عند حدوث الخطأ.

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

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_Rpi_0x26340500.bin.GCF

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

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

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

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

manup هل يمكن أن تكون هذه المشكلة مرتبطة؟ https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1657

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

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

https://ww8.ikea.com/ikeahomesmart/releasenotes/releasenotes.html

من المؤسف أنه لا يحتوي على تواريخ إطلاق ...

https://ww8.ikea.com/ikeahomesmart/releasenotes/releasenotes.html

من المؤسف أنه لا يحتوي على تواريخ إطلاق ...

يبدو أنه تم تحريره لأنني كنت قادرًا على تنزيل البرنامج الثابت كما هو موضح في ملاحظات الإصدار 2.3.007.

يجب أن يكون حوالي شهر يناير https://www.iphone-ticker.de/ikea-home-smart-homekit-und-bridge-update-verfuegbar-152574/

ليس لها مبرمج. أعتقد أنه لا ينبغي تثبيت r21 على conbee 2 وانتظر؟ هذه هي البرامج الثابتة بيتا؟

خارج الموضوع قليلاً: أيضًا برنامج ثابت جديد لـ Trådfri dimmer ، ترقيته إلى ZB3. بالرجوع إلى رقم 2485 ، سيكون لدينا نفس المشكلة بالنسبة إلى باهتة ... أتوقع أن يكون مستشعر الحركة من الطراز القديم هو التالي ...

وهنا الإصدار التجريبي لـ ConBee I و RaspBee مع إصلاح خطأ المسار.
آمل أن يجلب بعض التحسينات لاكتشاف طريق جديد عند حدوث الخطأ.

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

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_Rpi_0x26340500.bin.GCF

شكرًا ، manup ، فقط ثبته. دعونا نرى ما سيحققه.

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

ما رأيك بهذا؟

لقد قمت بتثبيت البرنامج الثابت على raspbee الخاص بي ، (لدي 73 عقدة معظمها من ايكيا) ، سأقوم بإبلاغ النتائج.

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

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

No.             Source          Transmit Dev    Receive Dev     Destination     Protocol        Info
39174           DeConz          DeConz          Gang 1          Gang 1          ZigBee HA       ZCL: Configure Reporting, Seq: 182
39180           DeConz          DeConz          Gang 1          Gang 1          ZigBee HA       ZCL: Configure Reporting, Seq: 183
39227           DeConz          DeConz          On/Off light 36 Badkamer ledstr ZigBee HA       ZCL: Read Attributes, Seq: 183

يجب إصلاح مشكلة الرقم التسلسلي في 2.05.74 ، والذي يتم إنشاؤه الآن وسيكون متاحًا في غضون ساعات قليلة.

https://github.com/dresden-elektronik/deconz-rest-plugin/commit/33d8a8b349c9f4967e8b94ed2657e038406317c8

وهنا الإصدار التجريبي لـ ConBee I و RaspBee مع إصلاح خطأ المسار.
آمل أن يجلب بعض التحسينات لاكتشاف طريق جديد عند حدوث الخطأ.
بالنسبة للاختبار ، أعتقد أنه سيكون من الجيد أن يتم تشغيله لبضعة أيام / أسابيع فقط وسنرى ما إذا كانت الأضواء لا تزال تتوقف عن الاستجابة للإرسال الأحادي. في هذه الحالة ، يرجى المحاولة إذا كانت الأضواء لا تزال تتفاعل مع أوامر المجموعة أو صامتة تمامًا.
http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_Rpi_0x26340500.bin.GCF

شكرًا ، manup ، فقط ثبته. دعونا نرى ما سيحققه.

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

ما رأيك بهذا؟

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

ما رأيك بهذا؟

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

حسنًا ، لقد حصلت على هذه الأشياء مع Zolder and Garage (من عدد من المنشورات) وحصلت على هذا السلوك:

No.             Source          Transmit Dev    Receive Dev     Destination     Protocol        Info
163778          Garage          Kerstverlicht   DeConz          DeConz          ZigBee          Route Record, Dst: 0x0000
163779                                                                          IEEE 802.15.4   Ack

أظهر سجل الطريق:

Command Frame: Route Record
    Command Identifier: Route Record (0x05)
    Relay Count: 1
    Relay Device 1: 0x731e[Kerstverli]

يقوم الاتصال التالي من DeConz إلى Garage بما يلي:

No.             Source          Transmit Dev    Receive Dev     Destination     Protocol        Info
163788          DeConz          DeConz          Zolder          Garage          ZigBee          APS: Ack, Dst Endpt: 0, Src Endpt: 0

لذلك من الواضح أنها لا تستحوذ على تسجيلات المسار.

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

نجاح! أستطيع أن أؤكد أن السلوك الآن هو أنه بعد فشل الارتباط غير الشجري ، يبدأ اكتشاف المسار بالفعل.

No.             Source          Transmit Dev    Receive Dev     Destination     Protocol        Info
173142          DeConz          Buiten - R sch  Tuin rechtsach1 Tuin rechtsach1 ZigBee ZDP      Bind Request, Basic (Cluster ID: 0x0000) Src: SiliconL_ff:fe:16:47:5f, Dst: dresden-_ff:ff:00:c4:9a
173143          Buiten - R sch  Buiten - R sch  DeConz          DeConz          ZigBee          Network Status, 0x35b7: Non-tree Link Failure
173144                                                                          IEEE 802.15.4   Ack
173206          DeConz          DeConz          Broadcast       Broadcast       ZigBee          Route Request, Dst: 0x35b7, Src: 0x0000

يجب إصلاح مشكلة الرقم التسلسلي في 2.05.74 ، والذي يتم إنشاؤه الآن وسيكون متاحًا في غضون ساعات قليلة.

33d8a8b

"swversion": "2.5.74",

: ابتسامة: شكرا @ manup وقت الاستجابة الرائع: 1st_place_medal:

يرجى انتظار التحديث إلى 2.05.74 ، أو استخدم http://phoscon.de/app لإظهار تطبيق Phoscon. لقد رأينا للتو أن صفحة البوابة غير المتصلة بالإنترنت تظهر في بعض الصفحات حيث لا ينبغي أن يتم إعادة بنائها الآن لمدة ساعتين تقريبًا.

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

إليك أول برنامج اختبار ثابت لـ ConBee II

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_R21_0x26520700.bin.GCF

سيتم الآن إعادة نقل هذا إلى البرامج الثابتة ConBee I / RaspBee ، عبر الإنترنت قريبًا.

هذا المهاجم لا يعمل بالنسبة لي. يُظهر جميع أجهزتي على أنها متصلة ، ولكن لم يتم إنشاء شبكة. لم يتم عرض الاتصالات في واجهة المستخدم الرسومية ، ولم يعمل أي تبديل من Phoscon (2.05.74). تومض Conbee II إلى 264A0700 وكل شيء يعمل من جديد كما هو متوقع ...

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

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

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

قد يستغرق الأمر بعض الوقت حتى يتم بناء الشبكة ، ولكن يجب أن ترى خطوطًا بعد 5-10 دقائق.

هذا المهاجم لا يعمل بالنسبة لي.

كذلك هنا ، Rasperry Pi 4B، deCONZ 2.05.74، ConBee II. شبكة اختبار صغيرة مع مكرر Trådri و Trådfri plug و XBee و Trådfri dimmer و 2 مستشعرات Trådfri للحركة (القديمة والجديدة) ومفتاح Trådri On / Off. لا يبدو أن البوابة ترسل أو تستقبل أي حركة مرور من أي جهاز. رؤية قطع اتصال USB في سجل النظام. كل شيء أصبح جيدًا مرة أخرى ، بعد الوميض مرة أخرى إلى 4A.
log.gz

تومض للتو مرة أخرى للاختبار:

• لا توجد خطوط في واجهة المستخدم الرسومية (اتركها تعمل لمدة 15 دقيقة)
• يبدو اتصال USB مستقرًا
• لا تزال مفاتيح UBISYS C4 و D1 تعمل
• أزرار Tradfri لا تفعل ذلك

ebaauw يظهر السجل أن المنسق يرى جارين فقط مع هذا الإصدار.

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

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

هل تستخدم كبل تمديد USB ، أم أن ConBee II متصل مباشرة؟

بالنسبة لي يعمل بشكل جيد على Raspbee ...

في RaspBee و ConBee 1 فقط تم تضمين إصلاح المسار في الإصدار الجديد (البرامج الثابتة المختلفة).

يُظهر السجل أن المنسق يرى جارتين فقط مع هذا الإصدار.

نعم ، ظهر اثنان من الأجهزة الطرفية كجيران في واجهة المستخدم الرسومية. غريب كندة ، لأنهم أظهروا أنهم متصلون بجهاز توجيه آخر بعد خفض مستوى البرامج الثابتة ConBee II.

هل تستخدم كبل تمديد USB ، أم أن ConBee II متصل مباشرة؟

لقد تم توصيله مباشرة منذ أن حصلت عليه. إلى منفذ USB-2 على Pi ، مع توصيل XBee بمنفذ USB-2 الآخر ؛ لا شيء على USB-3. كان الاتصال مستقرًا ، إلا عندما قمت بتكوين ConBee II كموجه (انظر # 2463).

في RaspBee و ConBee 1 فقط تم تضمين إصلاح المسار في الإصدار الجديد (البرامج الثابتة المختلفة).

لم أجرب ذلك بعد. سوف تضطر إلى الانتظار حتى وقت لاحق ...

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

لقد لاحظت في de_web_plugin_private.h

#define IDLE_ATTR_REPORT_BIND_LIMIT 1800

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

يبدأ المسار مقابل badkamer ledstrip ، وفقًا لـ DeConz ، بـ On/Off light 36 الذي من الواضح أنه لا يعرف كيفية الوصول إلى هناك. لذلك يبدأ في اكتشاف الطريق ويكتشف أخيرًا أنه يمكنه (بالكاد ، على ما أعتقد) الوصول إلى ledstrip نفسه. مسار العودة من خلال Gang 1

يبدو أن On/Off light 36 ينسى حوالي Badkamer ledstrip كل مرة تتم فيها معالجة طلب مسار متعدد إلى واحد ...

No.               Source            Transmit Dev      Receive Dev       Destination       Protocol          Info
177114            DeConz            DeConz            On/Off light 36   Badkamer ledstrip ZigBee HA         ZCL: Read Attributes, Seq: 55
177115                                                                                    IEEE 802.15.4     Ack
177116            On/Off light 36   On/Off light 36   Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177117            On/Off light 36   HK plafond ledstrip                 Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177118            On/Off light 36   HK zoutlamp       Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177119            On/Off light 36   Zoldertrap Lamp   Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177120            On/Off light 36   Kerstverlichting  Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177121            On/Off light 36   HK stalamp        Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177122            On/Off light 36   DeConz            Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177123            On/Off light 36   HK houtlamp 2     Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177124            On/Off light 36   Keuken links      Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177125            On/Off light 36   Keuken Rechts     Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177126            On/Off light 36   HK houtlamp       Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177127            On/Off light 36   Keuken mid        Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177128            On/Off light 36   Tuin linksvoor 2  Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177129            On/Off light 36   WC lamp           Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177130            0x6666            0x6666            0x6666            0x6666            IEEE 802.15.4     Data, Dst: 0x6666, Src: 0x6666, Bad FCS
177131            On/Off light 36   Gang 1            Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177132            On/Off light 36   Hal lamp          Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177133            DeConz            On/Off light 36   Badkamer ledstrip Badkamer ledstrip ZigBee HA         ZCL: Read Attributes, Seq: 55
177134                                                                                    IEEE 802.15.4     Ack
177135            Badkamer ledstrip Badkamer ledstrip Gang 1            DeConz            ZigBee            Command, Dst: DeConz, Src: Badkamer , Bad FCS
177136                                                                                    IEEE 802.15.4     Ack
177137            On/Off light 36   Voordeur          Broadcast         0xfcfd            ZigBee            Command, Dst: 0xfcfd, Src: On/Off li, Bad FCS
177138            Badkamer ledstrip Gang 1            DeConz            DeConz            ZigBee            Route Record, Dst: 0x0000

الاتصال التالي:

No.               Source            Transmit Dev      Receive Dev       Destination       Protocol          Info
177366            DeConz            DeConz            On/Off light 36   Badkamer ledstrip ZigBee HA         ZCL: Read Attributes, Seq: 58

محاولة أخرى لبرنامج ConBee II الثابت:

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26530700.bin.GCF

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

تلقيت هذا الخطأ ، في كل مرة أحاول فيها التحديث إلى أحدث البرامج الثابتة. أي تلميحات لماذا؟
rich710 @ RichHassPc01 : ~ $ sudo GCFFlasher_internal -d / dev / ttyACM1 -f deCONZ_ConBeeII_0x26530700.bin.GCF
GCFFlasher V3_13 (c) Dresden elektronik ingenieurtechnik GmbH
جهاز إعادة التشغيل / dev / ttyACM1 (ConBee II)
إصدار البرنامج الثابت deCONZ 26490700
محمل الإقلاع R21B18
الإصدار: 2.05
البناء: 22 مارس 2019
وميض 161378 بايت: | =============================== |
تحقق: .
فشل تحديث الفلاش ، CRC غير صالح. حاول مرة اخرى.
rich710 @ RichHassPc01 : ~ $

هل تحققت من مجموع MD5 للملف الذي تم تنزيله؟ (http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26530700.bin.GCF.md5)

نعم ، لقد قمت بالتحقق والتنزيل عدة مرات ، بل حاولت العودة إلى البرامج الثابتة القديمة ، وسارت الأمور بشكل جيد حتى الآن. أنا الآن عالق بهذا الخطأ ، لقد أعدت تشغيل NUC عدة مرات ولكن ما زلت عالقًا عندما يحاول flasher إعادة تشغيل ConbeeII.
rich710 @ RichHassPc01 : ~ $ sudo GCFFlasher_internal -d / dev / ttyACM1 -f deCONZ_ConBeeII_0x26490700.bin.GCF
[sudo] كلمة مرور rich710:
GCFFlasher V3_13 (c) Dresden elektronik ingenieurtechnik GmbH
جهاز إعادة التشغيل / dev / ttyACM1 (ConBee II)

2139: خطأ: فشل إعادة تعيين uart ، تحقق من إعادة المحاولة

لاحظت أنك تستخدم ttyACM1 ، عند استخدام

GCFFlasher -l

سيظهر الرقم التسلسلي.
يمكنك استخدامه لتوفير اسم جهاز أكثر استقرارًا في الأمر.

GCFFlasher_internal -sn DE1948474 -f deCONZ_ConBeeII_0x26530700.bin.GCF

(استبدل بالرقم التسلسلي لجهازك)

آسف لم ينجح ، ربما يجب أن أنقله إلى جهاز Windows الخاص بي وأجرّب
rich710 @ RichHassPc01 : ~ $ GCFFlasher_internal -l
GCFFlasher V3_13 (c) Dresden elektronik ingenieurtechnik GmbH
المسار | البائع | المنتج | المسلسل | نوع
----------------- + -------- + --------- + ------------ + -------
/ dev / ttyACM1 | 0x1CF1 | 0x0030 | DE1964163 | ConBee الثاني
/ dev / ttyUSB0 | 0x0403 | 0x6001 | A1YV35M2 | عام FTDI
rich710 @ RichHassPc01 : ~ $ GCFFlasher_internal -sn DE1964163 -f deCONZ_ConBeeII_0x26530700.bin.GCF
GCFFlasher V3_13 (c) Dresden elektronik ingenieurtechnik GmbH
جهاز إعادة التشغيل (ConBee II)

2139: خطأ: فشل إعادة تعيين uart ، تحقق من إعادة المحاولة
rich710 @ RichHassPc01 : ~ $

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

• افصل ConBee II
• GCFFlasher_internal -t 60 -sn DE1964163 -f deCONZ_ConBeeII_0x26530700.bin.GCF
• قم بتوصيل ConBee II مرة أخرى

تتيح المعلمات -t لـ GCFFlasher المحاولة لمدة دقيقة واحدة لمعالجة التحديث.

لقد عملت على تحديث البرنامج الثابت في windows ، وعندما قمت بتوصيله في NUC الخاص بي مع ubuntu مرة أخرى ، تم توصيله. ولكن ، بعد ساعة واحدة الآن ، تم توصيله للتو بـ 4 أوم عقدتي ..: S.

تجربة أخرى على البرنامج الثابت ConBee II: http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26530700.bin.GCF

لا مزيد من قطع اتصال USB ، ولكن يبدو أن deCONZ تعيد اكتشاف ConBee II كثيرًا. لا تزال هناك حركة مرور.
log.gz

تحرير من أجل دعابة لك ، قمت بفصل XBee واستخدمت كابل تمديد USB 10 سم لتوصيل ConBee II: لا تغيير.

محاولة أخرى لبرنامج ConBee II الثابت:

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26530700.bin.GCF

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

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

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

واجهmanup نفس المشكلات بعد وميض البرنامج الثابت ، لكن الضغط على جهاز إعادة التشغيل في deconz / إعادة تشغيل deconz جعل الروابط تعود.

وهنا الإصدار التجريبي لـ ConBee I و RaspBee مع إصلاح خطأ المسار.

يبدو أنه يعمل بشكل جيد على نظام اختبار Pi 3B +. سأنتظر حتى نهاية هذا الأسبوع قبل ترقية شبكة الإنتاج الخاصة بي.

ebaauw ، هل أتذكر بشكل صحيح أنك أجريت الكثير من هذه التحقيقات في سلوك منسق ايكيا؟ هل تفعل ذلك أيضا؟

أضفت دعمًا لمعظم أجهزة Trådfri ، لكنني لم أتمكن من التعرف على أي حركة مرور ZigBee من / إلى مركز Trådfri. إنه يستخدم فقط اقتران اللمس ، وما زلت أحاول التقاط ذلك لاستعادة مفتاح الشبكة. هذا هو ، على افتراض أنه ممكن على الإطلاق.

لقد كنت أقوم بتشغيل FW الجديد على العصا conbee 1 في إعداد ~ 40 عقدة منذ إصدار البرنامج الثابت الجديد وكان يعمل بشكل رائع دون أي مشاكل! (في الصورة ، العقد غير المتصلة إما نفدت البطارية أو لا تعمل بالطاقة)

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

لا يعمل لدي. تقريبا لا اتصالات في الشبكة. لقد انتظرت حوالي 20 دقيقة بعد إعادة التشغيل.

Raspberry Pi 3 Model B Rev 1.2.1 تحديث
Conbee الثاني
الإصدار 2.05.74
الإصدار 26530700

77 عقدة

3 اتصال بـ
1 مفتاح تشغيل / إيقاف TRÅDFRI
1 مستشعر متعدد Xiaomi
1 مفتاح التعتيم من Philips
أنا قادر على تشغيل الأحداث من مفتاح تعتيم فيليبس.
هذه التي لها اتصالات قريبة جدًا من عصا Conbee. العصا موجودة في المرآب. لدي بعض المصابيح في المرآب ليس بها وصلات.

لا يوجد اتصال
الكثير من لمبات ايكيا ، كلا من E27 و GU10
الكثير من أجهزة الاستشعار المتعددة Xiaomi
الكثير من جهاز التحكم عن بعد Ikea TRÅDFRI
والعقد الأخرى.

السجلات
27 فبراير 09:29:06 raspberrypi systemd [1]: تم بدء deCONZ: ZigBee gateway - GUI / REST API.
27 فبراير 09:29:06 raspberrypi deCONZ [7204]: تحذير libEGL: DRI2: فشل في المصادقة
27 فبراير 09:29:06 raspberrypi deCONZ [7204]: تحذير libpng: iCCP: ملف تعريف sRGB غير صحيح معروف

عند التخفيض إلى 264A0700 ، تبدأ في بناء الشبكة مباشرة.

ebaauw ، هل أتذكر بشكل صحيح أنك أجريت الكثير من هذه التحقيقات في سلوك منسق ايكيا؟ هل تفعل ذلك أيضا؟

أضفت دعمًا لمعظم أجهزة Trådfri ، لكنني لم أتمكن من التعرف على أي حركة مرور ZigBee من / إلى مركز Trådfri. إنه يستخدم فقط اقتران اللمس ، وما زلت أحاول التقاط ذلك لاستعادة مفتاح الشبكة. هذا هو ، على افتراض أنه ممكن على الإطلاق.

صحيح ، آسف. يجب أن تتحقق من git blame. تم تقديم الكود الذي يشير إلى سلوك بوابة ايكيا بالفعل في 48d2c39a267b5c6d025577eed7530be27932aa2c بواسطة manup ...

manup ، هل حددت بالفعل أن بوابة ايكيا تعيد تكوين السمة التي تبلغ عن ذلك كثيرًا؟ لماذا يلزم إعادة التكوين ؛ هل يجب تذكير الضوء بانتظام؟

ترقية Conbee I إلى beta FW و deCONZ .74

شبكة يبني على الفور ويبدو لطيفا حقا!

شكراً جزيلاً لـ djwlindenaar . أنا معجب للغاية بأنك أتيت من العدم وتجد مثل هذه الأخطاء الشديدة. وشكرا manup كذلك بالطبع

Conbee I و .74 أيضًا. تمت ترقية Ikea FW إلى 2.3.007 (البعض الآخر 2.x).
تحسن كبير! لا المتسربين حتى الآن!

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

شيء ما اكتشفته في هذه العملية:
تعمل المجموعة العادية ON-OFF - بسرعة ، ولكن بعد استدعاء مشهد (بعد التلاشي في الوقت المناسب) وإيقاف تشغيله مرة أخرى (أقل من 10 ثوانٍ) ، تنطفئ الأضواء فقط في واجهة المستخدم الرسومية (بغض النظر عن واجهة المستخدم القديمة أو الجديدة) ثم يعود بعضها مرة أخرى (في واجهة المستخدم الرسومية) في المجموعة بينما لا تزال جميع المصابيح المادية تعمل. بعد الضغط مرة ثانية أو ثالثة OFF ، فإنها تصبح مظلمة في بعض الأحيان.

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

اكتشفت أنه يعمل كالمعتاد عندما أنتظر لفترة أطول قليلاً. دعنا نقول 15-20 ثانية. ثم تنطفئ الأضواء كالمعتاد. أفترض أن ديكونز تشعر بالارتباك كما يحدث عندما تقوم بإطفاء الضوء حتى يتلاشى.

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

لقد اختبرت قليلا. لدينا تغيير في السلوك. في السابق ، عندما تم تغيير bri بسرعة معينة ، أو كان للمشهد وقت انتقال أطول ، كان من الممكن المقاطعة بأمر جديد. حتى الإجراء السابق كان لا يزال قيد التنفيذ ، تم وضع الأمر التالي في قائمة الانتظار. الآن فقدها. مصابيح أرضية Egmy تعمل بجهاز استشعار الحركة. قبل أن يخرجوا من أعتيمهم وانتظر لمدة 10 ثوانٍ قبل إيقاف تشغيلهم. عندما أطلقت الحركة واستدعت المشهد أثناء تلاشيهم ، فقد الأمر. قبل ذلك تم وضعها في قائمة الانتظار وتنفيذها بعد ذلك. هل هذا بسبب. 74 أو البرامج الثابتة الجديدة؟ شكر

لم يقم My Conbee II ببناء شبكة على الإصدار التجريبي. الشيء الوحيد الذي يمكنني التفكير فيه يمكن أن يكون مختلفًا عن الإعدادات "العادية" هو ضبط القناة على 25. بالعودة إلى 264a0700 ، تم إصلاحها

realwax ، أعتقد أنك تواجه خطأ في البرامج الثابتة Trådfri ، راجع # 2068. يمكنك التحقق من ذلك بسهولة عن طريق إصدار أمر بفترة انتقال أطول في واجهة المستخدم الرسومية ثم إصدار أمر ثانٍ.

قبل ذلك تم وضعها في قائمة الانتظار وتنفيذها بعد ذلك.

هل قمت بتحديث البرنامج الثابت الخفيف؟ هل أنت متأكد أنك تستخدم نفس الضوء؟ لا يتتبع المكون الإضافي REST API وقت الانتقال بمجرد إرسال أمر إلى الضوء.

ebaauw أشكرك على

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

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

لست متأكدًا مما إذا كان تطبيق Trådfri يدعم تحديد أوقات انتقال أطول ، لكن وحدات التحكم التي رأيتها لا تدعم ذلك. ربما لن تتمكن من إرسال أوامر من وحدات التحكم بشكل أسرع من وقت الانتقال الافتراضي للأضواء. وإذا قمت بذلك في بعض الأحيان ، فربما تعتقد أنك لم تضغط على الزر بالكامل.

ebaauw أرى. ما لا يزال يحيرني هو حقيقة أنه يمكنني تشغيل وإيقاف مجموعة من E14 (توفير نوع من الديسكو الخفيف ؛)) في غضون ثانية واحدة (on-off-on) تعمل! ولكن بمجرد الضغط على زر استدعاء المشهد في deconz ، لا يمكنني ذلك ويصبح السلوك غريبًا. هذا هو المكان الذي أشك فيه بطريقة ما أنه خطأ IKEA. لماذا يمكنني التبديل وإيقاف التشغيل بسرعة كبيرة ولكن بمجرد أن أتذكر مشهدًا ، أكون عالقًا على الأقل لمدة 5-10 ثوانٍ؟

الأوقات المُقاسة بدقة (20 محاولة):
مجموعة 8 E14
المجموعة تشغيل -> إيقاف المجموعة - التبديل مرة واحدة ثانية
استدعاء المشهد -> تشغيل -> إيقاف لا يستجيب حتى 10-12 ثانية!

أتفهم أنه مع الاستدعاء يتم إنشاء المزيد من حركة المرور وكل مصباح يتلقى رسائل أكثر ، ولكن بفارق 10 ثوانٍ؟ حتى عندما أقوم بتغيير bri و ct لمجموعة كاملة ، يمكنني إيقاف تشغيله في ثانية ولكن مرة أخرى ، يشبه الاستدعاء التجميد. أعتقد أن هذه مشكلة ديكونز ، أليس كذلك؟

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

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

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

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

قد تحاول إعادة إنشاء المشهد الخاص بك ، لكن لا توجد ضمانات ...

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

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

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

سأقوم الآن باسترجاع / تخفيض البرنامج الثابت إلى 1.x ومعرفة ما إذا كان يعمل بشكل أفضل. سأعود تقرير.

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

كنت أبحث بعمق أكثر في شيء الإبلاغ عن السمات. كنت أتساءل عما إذا كان التكوين المتكرر للإبلاغ عن السمة كل 30 دقيقة (1800s) يتسبب في توقف البرامج الثابتة الخفيفة.
لقد لاحظت هذا الجزء من الكود الذي لا يبدو أنه يتعامل مع rq.maxinterval == 0 بشكل صريح. الآن كيفية التعامل مع هذه الحالة بشكل صحيح أمر صعب بعض الشيء ، نظرًا لأن rq.maxinterval == 0 يعني أن الضوء سيبلغ عن التغيير فقط ، لذلك لا توجد مهلة "جيدة" لهذه الحالة ... ربما يكون التنفيذ الحالي جيدًا ، على الرغم من أتساءل عما إذا كانت هناك فكرة أفضل.

bool DeRestPluginPrivate::sendConfigureReportingRequest(BindingTask &bt, const std::vector<ConfigureReportingRequest> &requests)
{
<hidden>
        if (val.clusterId == bt.binding.clusterId)
        {
            // value exists
            if (val.timestampLastReport.isValid() &&
                val.timestampLastReport.secsTo(now) < qMin((rq.maxInterval * 3), 1800))
            {
                DBG_Printf(DBG_INFO, "skip configure report for cluster: 0x%04X attr: 0x%04X of node 0x%016llX (seems to be active)\n",
                           bt.binding.clusterId, rq.attributeId, bt.restNode->address().ext());
            }
 ```

I Did some experiments, including asking the IKEA lights to report `ONOFF` and `LEVEL` periodically instead of only when a change is made. The lights happily report their status periodically, so that may be an acceptable way to avoid the above issue. To be verified properly of course.

Anyway, while doing these experiments, I stumbled upon an actual bug. I noticed the magical Default Response Command being returned whenever the IKEA lights now report their attributes. So I looked into what that thing is. Apparently that is supposed to conclude an ZCL/APS transaction when requested. There's a bit in the ZCL packet which dictates whether or not it should be sent `Disable Default Response`.

For attribute reports these are handled nicely by deCONZ

لا. الوقت المصدر إرسال مطور استلام وجهة ديف تعطيل معلومات الاستجابة الافتراضية
208134 10 ساعة 43 دقيقة 23.151 ثانية عصابة 1 عصابة 1 DeConz DeConz False ZCL: سمات التقرير ، التسلسل: 15
208136 10 س 43 د 23.158 ث DeConz DeConz عصابة 1 عصابة APS: Ack، Dst Endpt: 1، Src Endpt: 1
208138 10 ساعة 43 دقيقة 23.212 ثانية DeConz DeConz Gang 1 Gang 1 True ZCL: الاستجابة الافتراضية ، تسلسل: 15

However for Configure Reporting Response command, deCONZ fails to send the Default Response. I'm not sure how the IKEA lights handle this situation, but it may be a cause for a memory leak. Remembering that the Default Response is a kind of closure of the transaction, it may be that the firmware only releases a certain amount of memory after it is received.

لا. الوقت المصدر إرسال مطور استلام وجهة ديف تعطيل معلومات الاستجابة الافتراضية
207941 10 ساعة 43 دقيقة 8.422 DeConz DeConz Gang 1 Gang 1 True ZCL: تكوين التقارير ، التسلسل: 41
207949 10 س 43 د 8.481 عصابة 1 عصابة 1 DeConz DeConz False ZCL: تكوين استجابة الإبلاغ ، التسلسل: 41
207951 10 س 43 د 8.485 عصابة 1 عصابة 1 DeConz DeConz APS: Ack، Dst Endpt: 1، Src Endpt: 1
207952 10 س 43 د 8.487 DeConz DeConz Gang 1 Gang 1 APS: Ack، Dst Endpt: 1، Src Endpt: 1
207954 10 س 43 د 8.493 عصابة 1 عصابة 1 DeConz DeConz APS: Ack، Dst Endpt: 1، Src Endpt: 1

I'm going to test this hypothesis with this patch in place:
```diff
diff --git a/bindings.cpp b/bindings.cpp
index 9607b09..0c2b5fc 100644
--- a/bindings.cpp
+++ b/bindings.cpp
@@ -443,6 +443,12 @@ void DeRestPluginPrivate::handleZclConfigureReportingResponseIndication(const de
         allNodes.push_back(&l);
     }

+    // send DefaultResponse if not disabled
+    if (!(zclFrame.frameControl() & deCONZ::ZclFCDisableDefaultResponse))
+    {
+        sendZclDefaultResponse(ind, zclFrame, deCONZ::ZclSuccessStatus);
+    }
+
     for (RestNodeBase * restNode : allNodes)
     {
         if (restNode->address().ext() != ind.srcAddress().ext())

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

نعم ، يتحقق المكون الإضافي REST API من عمل تقرير السمات. إذا لم يكن الأمر كذلك ، فسيحاول إعادة تكوينه ، وأعتقد أنه يعود أيضًا إلى استطلاع الجهاز.

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

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

هناك القليل في حزمة ZCL التي تحدد ما إذا كان يجب إرسالها أم لا Disable Default Response .

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

هناك القليل في حزمة ZCL التي تحدد ما إذا كان يجب إرسالها أم لا Disable Default Response .

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

ebaauw ، في الواقع. هذا بالضبط هو الهدف. فشل deCONZ في إرسال Default Response ردًا على Configure Reporting Response . يحدث أن أضواء ايكيا تطلب Default Response Configure Reporting Response .
لذلك ، كما تقول ، قد يكون هذا هو السبب ، إلى جانب Configure Reporting Request كل نصف ساعة ، لأضواء ايكيا لتذهب بعيدًا.

فقط للتذكير:
تصبح لمبات Ikea (E27 & GU10 v1) أحيانًا غير قابلة للوصول وتحتاج إلى دورة طاقة عند الاتصال بجسر HUE أيضًا ، لذا فإن هذه المشكلة المعينة ليست فريدة من نوعها لـ Conbee I / II
من بين 16 E27 و 12 GU10 على جسر HUE الخاص بي ، أود أن أقول أن لمبة واحدة `` معلقة '' كل أسبوع إلى أسبوعين تقريبًا. أحيانًا أطول وأحيانًا أسرع. تم تحسين هذه المشكلة مع أحدث إصدارات البرامج الثابتة HUE على مدار العام ونصف العام الماضيين.

all ما هو إصدار البرنامج الثابت Tradfri الذي تستخدمه؟

هل أنت في 1.x أو 2.x؟ مع 2.x قدموا zigbee 3.0. قمت بالترقية إلى 2.x وبدأت المشكلة. لمبات E14. لقد لاحظت تحسينات فيما يتعلق بسرعة الشبكة والاتصال. لكن شيئين جعلني أتراجع 20 مصباحًا تنهدًا لم يعد "التشغيل الناعم" يعمل بعد الآن. تم تشغيل المصابيح دون أن يبهت. المشاهد لم تكن تعمل كما اعتادت. التحدث بدقة بعد تذكر مشهد كان هناك وقت انتظار قبل إطفاء الضوء أو استدعاء szene التالي ، وإلا فإن deconz أصبح غير متزامن وأعيد تشغيله بينما اللمبة لم تفعل شيئًا.

أنا أقدر تجربتك المشتركة مع الإصدارات و deconz `` بلا عيوب '' مع 2.x يبدو أنه لم يتم تقديمه.

هل هناك توصية؟ مهاجم ضد؟ بجانب مشكلة الاتصال المفقود ومشكلات الاتصال على Ikea's fw نفسها ، يبدو أن deconz يمكنه التعامل مع 1.x بشكل أفضل.

شكر!

انا استخدم:

• Conbee 1 مع البرامج الثابتة 0x26340500
• Deconz الإصدار 2.05.73 (باستخدام حاوية رصيف marthoc على دبيان)
• ~ 60 عقدة ، معظمها IKEA Trådfri
• لم يتم تثبيت Conbee 1 (المنسق) مركزيًا في منزلي الذي تبلغ مساحته 200 متر مربع. يعتمد النظام بشكل كبير على التجوال والتشبيك.
• يتم تثبيت عصا Conbee 1 على كابل تمديد USB بطول 0.5 متر ومثبتة على جانب الرف حيث يوجد الكمبيوتر لتوفير مساحة خالية أكبر لإشارات التردد اللاسلكي.

منذ الترقية (في نفس اليوم الذي تم إصداره فيه) لـ Conbee 1 sticks firmware deconz يعمل مثل السحر ! لا توجد قضايا على الإطلاق.

ترقية شبكة الإنتاج الخاصة بي (RPi 3B + ، تمتد ، RaspBee) إلى 2.05.74 و 0x26340500 أمس. يبدو مستقرًا ، باستثناء المشكلات أدناه.

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

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

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

تضمين التغريدة
ما هي البرامج الثابتة التي تستخدمها على المصابيح الخاصة بك tradfri؟ هذا يحدث فرقًا حتى في هذا الموضوع فيما يتعلق بمشكلة الاتصال المفقودة بقدر ما اختبرت. نتائجي هي أن الخطوات المتخذة هنا حسنت تشغيل 1.x لمبات tradfri التي تعمل على Conbee 1. لكن شبكة 20 e14 مع tradfri fw 2.3.x هي فوضى. التوقيتات ، المشاهد عالقة ، ديكونز يحصل ، الضوء يبدأ بالوميض (ضائع؟) ، .. كما ورد أعلاه. أعتقد أن هذه نقطة يجب مناقشتها وذكرها لتقديم توصية واضحة من ikea fw لاستخدامها في تجربة جيدة. ربما هناك مقال git بالفعل. ولكن من تجربتي لا تقم بالترقية 😅

لذلك من وجهة نظري وساعات من الاختبار والوميض. شكرًا لك على التحسين الذي طرأ على IKEA fws 1.x! هل من الممكن التخفيف من المشكلات الحالية عند تشغيل 2.x؟ وإلا فلن يكون من الممكن الترقية إلى zigbee 3 من ايكيا حاليًا. يبدو أن السلوك تغير وأن تشغيلها في ديكونز يجب أن يتكيف. ربما هذا بالنسبة لـ ebaauw للحكم أو التعامل معه؟

في صحتك
أتمنى لك يوم أحد 😊

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

اتفق على الفوضى مع جميع "الأجزاء المتحركة" في نفس الوقت في محاولة لتحديد السبب الجذري للمشاكل

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

شكرا لك على قائمتك.

بالنظر بشكل خاص إلى أجهزة التوجيه (المصابيح) ، أرى أنك تعمل 2.3.007 على E14s. هل يمكنك إعادة إنتاج قائمة مشكلتي. https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2518
نظرًا لأنني لم أكن على دراية بالترقية التلقائية إلى 2.3.x ، فقد كانت شبكتي مختلطة بـ 1.x و 2.x ليست جيدة جدًا. قمت بالترقية يدويًا إلى 2.3.x ثم ساءت الأمور. (شبكة أسرع ولكن قابلية الاستخدام الهائلة تنخفض ، وتسقط اللمبات الوامضة) لذلك يمكنني أن أوصي إذا واجهت المصابيح الوامضة في جهاز e14 أو "laggyness" على scences خفضها إلى 1.2 ... سأكون مهتمًا بالحصول على "مسؤول" بيان احترافي من مطورينا المحترفين هنا حول هذا الموضوع. أنا متأكد من أنه كان هناك وقت تم فيه التعامل مع deconz مع 1.2 بالمثل وتم تحسينه. أشعر أن هذا يحتاج إلى القيام به لمدة 2.3.x أيضًا أو أفسدت Ikea الأمر بنفسها. من الصعب القول لأنني لست عميقًا في الكود.

تضمين التغريدة
أنا أستخدم ميزة otau الخاصة بـ deconz والبرنامج النصي لتحديث البرامج الثابتة لتنزيل ملفات fw.
لا أعرف لماذا لم يتم تحديث E14s ... huhum.

كيف قمت "يدويًا" بتحديث / تقليل إصدار المصابيح؟

حسنا حسنا. كل شيء يعمل بشكل جيد ويتم تنفيذ غالبية التوجيه بواسطة E27s مع fw 2.3.x وبرامج تشغيل لوحة Jormen و FLOALT.

تضمين التغريدة
من المثير للاهتمام أنك لا تواجه هذه المشكلات. ربما يكون ذلك بسبب حجم الشبكة. لدي 23 مصباحًا من 20 e14 في 2.3.007. لقد ألغيت تنشيط otau التلقائي لأنه أفسد قابليتي للاستخدام مع البرامج الثابتة الجديدة. عبر Gui ، يمكنك الرجوع إلى إصدار أقدم باستخدام زر التحديث. اختر البرنامج الثابت المناسب أولاً ، اضغط على "تحديث" وربما مرة أخرى. تم إيقاف حالة النموذج مؤقتًا وتنتقل إلى -> في قائمة الانتظار -> الخمول -> بدء تحديث البرامج الثابتة (النسبة المئوية). في بعض الأحيان يتوقف. في وقت ما تحتاج إلى إعادة تشغيل الكمبيوتر. في وقت ما يكفي cyle السلطة. تحتاج أحيانًا إلى تقريب المصباح من المنسق.

يبدو أن السلوك تغير وأن تشغيلها في ديكونز يجب أن يتكيف. ربما هذا بالنسبة لـ ebaauw للحكم أو التعامل معه؟

لست متأكدا مما تقصده هنا. لقد تعاملت مع بعض الاختلافات بين البرامج الثابتة ZLL و ZB3 لوحدات التحكم (Trådfri remote و Trådfri wireless dimmer) ، راجع # 2485. هذا على مستوى APS في ZigBee stack ، ويتم التعامل معه بواسطة المكون الإضافي REST API.

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

تضمين التغريدة
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2518
تحدث بدقة. لقد قمت بتضمين النتائج التي توصلت إليها مع 20 شبكة E14 2.3.007 هنا. اختفت بعض الميزات واستدعى المشهد إلى حد كبير العبث بكل شيء لمدة 10 إلى 15 ثانية في تلك المجموعة. لا أعرف ما إذا كان هذا متعلقًا بالبرامج الثابتة فقط أو متعلق بـ deconz. هذا ما قصدته بالتغيير للتعامل معه. لذلك بالنسبة للعملية اليومية ، أرى أن 2.3.007 لا تذهب. مثال على قابلية الاستخدام: لم يعد تبديل المشاهد الدوارة التي تم تكوينها في الفوسكون يعمل بعد الآن عند عدم الضغط عليه بعناية مما يعني بعد تدوير المشهد للانتظار. بينما في 1.x ، يكون كل شيء سريعًا وجيدًا مع 2.3.x ، فإنه يتعطل.

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

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

manup ، هل وجدت بعض الوقت للنظر في هذا؟ وجدت هذا الصباح موقفًا حيث قمت بتدوير مصباح كهربائي (IKEA) على بعد 4 قفزات من المنسق. بطريقة ما ، قرر جهاز توجيه بين (أيضًا IKEA) أنه لا يعرف الطريق إلى هذا الضوء بعد الآن. أرى بالفعل الضوء يؤدي وظيفته بسعادة في التوجيه للأضواء الأخرى ، والإبلاغ عن حالة الارتباط والاستجابة لـ Network Address Request من deCONZ. هذا الأخير يحدث فقط لأن تلك الرسائل يتم بثها على الشبكة ..!
ومع ذلك ، فإن جهاز التوجيه الموجود بينهما يسقط بصمت أي إطارات أحادية الإرسال يجب أن يوجهها إلى هذا الضوء. بالطبع يجب ألا يقوم جهاز التوجيه هذا بإسقاطها بصمت ، ثم مرة أخرى ، يجب أن تكون deCONZ قوية ضد هذا السلوك السيئ.
في غضون ذلك ، يرسل الضوء لحسن الحظ رسائل تسجيل المسار إلى deCONZ أيضًا ، والتي تصل وتتجاهلها deCONZ.

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

ما رأيك بهذا؟

هذه البرامج الثابتة الجديدة لم تحل مشكلتي.

أستخدم Raspbee على Pi منفصل ومساعد منزلي (يعمل على NUC) ولدي appx. 25 أضواء Tradfri. يستخدم GU10 في الغالب في مجموعات من 3.

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

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

أريد أن أكون قادرًا على القيام بالتجميع في HASS ، لذا قمت بترقية Raspbee الخاص بي إلى 0x26340500 و Deconz إلى 2.05.74 وقمت بتغيير التهيئة إلى استخدام المجموعات الخفيفة في HASS. بعد تشغيل هذا لمدة أسبوع ، أصبحت المصابيح قديمة 3 أو 4 مرات ، وأنا الآن أعود إلى استخدام مجموعات Phoscon مرة أخرى.

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

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

ما رأيك بهذا؟

هذه نقطة جيدة ، أحتاج إلى التحقق من الكود الإضافي وكود البرنامج المساعد REST-API هنا ، لأنني أعتقد أن البرنامج الثابت يجب أن يقلل من "جودة" المسار بالفعل عندما لا يتم تلقي ACK على مستوى APS. APS ACK هي علامة يتم تعيينها اختياريًا في طلبات ZCL / APS وغالبًا ما يتم تعطيلها لخفض حركة مرور الشبكة. لذا فإن الفكرة التقريبية هي أنه يجب علينا تمكين APS ACK إذا اكتشف المكون الإضافي أن طلبات البث الأحادي تؤدي إلى انتهاء المهلة.

ربما يوجد جزء من هذا بالفعل ، تحتاج إلى التحقق من الرمز.

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

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

آلة الحالة الخاصة بذلك موجودة بالفعل في deCONZ core (هذا ما يؤدي إلى بث طلب عنوان NWK) ، يعمل هذا في حالة الروابط ذات القفزة الواحدة والأضواء التي تلتقط المسارات بناءً على الأوامر الواردة (الرد على بث). البث رائع لأنه يحترم أيضًا التغيير إلى عنوان NWK لأنه تم تضمين عنوان MAC. سأحاول إرسال إرسال أحادي باستخدام APS ACK الممكّن كخطوة تالية في حالة عدم تلقي أي رد.

لسوء الحظ ، اضطررت أمس إلى تشغيل مصباح IKEA E27 (برنامج ثابت أبيض 1000LM ، v1) أيضًا. كان يتفاعل فقط مع أوامر المجموعة ، ولكن ليس أوامر الإرسال الأحادي. يبدو أن المشكلة لم يتم حلها بعد :(

(ونعم أنا على الإصدار 74 والبرامج الثابتة التجريبية لـ RaspBee)

انظر التعليقات أعلاه ، قد تساعد التغييرات التالية في استعادة التوجيه.

ما رأيك بهذا؟

هذه نقطة جيدة ، أحتاج إلى التحقق من الكود الإضافي وكود البرنامج المساعد REST-API هنا ، لأنني أعتقد أن البرنامج الثابت يجب أن يقلل من "جودة" المسار بالفعل عندما لا يتم تلقي ACK على مستوى APS. APS ACK هي علامة يتم تعيينها اختياريًا في طلبات ZCL / APS وغالبًا ما يتم تعطيلها لخفض حركة مرور الشبكة. لذا فإن الفكرة التقريبية هي أنه يجب علينا تمكين APS ACK إذا اكتشف المكون الإضافي أن طلبات البث الأحادي تؤدي إلى انتهاء المهلة.

ربما يوجد جزء من هذا بالفعل ، تحتاج إلى التحقق من الرمز.

يبدو أنه حتى عند تعيين بت طلب APS ACK ، فإن deCONZ لا يفعل أي شيء مع ack المفقود (إعادة محاولة واحدة فقط ثم لا شيء ...)

BTW houtlamp 2 هو الشخص الذي يسقط الحزم الموجهة إلى Tuin linksvoor 2

No. Time    Source  Transmit Dev    Receive Dev Destination Disable Default Response    Info
245915  10h 28m 42.108501s  DeConz  DeConz  HK houtlamp 2   Tuin linksvoor 2    True    ZCL: Read Attributes, Seq: 245
245922  10h 28m 46.033452s  DeConz  DeConz  HK houtlamp 2   Tuin linksvoor 2    True    ZCL: Read Attributes, Seq: 245

ZigBee Application Support Layer Data, Dst Endpt: 1, Src Endpt: 1
    Frame Control Field: Data (0x40)
        .... ..00 = Frame Type: Data (0x0)
        .... 00.. = Delivery Mode: Unicast (0x0)
        ..0. .... = Security: False

        .1.. .... = Acknowledgement Request: True

        0... .... = Extended Header: False
    Destination Endpoint: 1
    Cluster: On/Off (0x0006)
    Profile: Home Automation (0x0104)
    Source Endpoint: 1
    Counter: 107

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

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

آلة الحالة الخاصة بذلك موجودة بالفعل في deCONZ core (هذا ما يؤدي إلى بث طلب عنوان NWK) ، يعمل هذا في حالة الروابط ذات القفزة الواحدة والأضواء التي تلتقط المسارات بناءً على الأوامر الواردة (الرد على بث). البث رائع لأنه يحترم أيضًا التغيير إلى عنوان NWK لأنه تم تضمين عنوان MAC. سأحاول إرسال إرسال أحادي باستخدام APS ACK الممكّن كخطوة تالية في حالة عدم تلقي أي رد.

في الواقع ، لا يرى houtlamp 2 أبدًا ردًا على البث address request . يتم توجيه الرسائل إلى deCONZ من خلال tuin linksvoor 3 ، لذلك حتى لو التقط houtlamp 2 هذا المسار ، فلن تحصل على الفرصة أبدًا. يحدث هذا مرة أخرى بسبب عدم قيام deCONZ باختيار route record كطريق جديد.

ZigBee Network Layer Command, Dst: DeConz, Src: Tuin link
    Frame Control Field: 0x1a09, Frame Type: Command, Discover Route: Suppress, Security, Destination, Extended Source Command
    Destination: 0x0000[DeConz]
    Source: 0x0ea5[Tuin linksvoor 2]
    Radius: 29
    Sequence Number: 51
    Destination: dresden-_ff:ff:00:c4:9a (00:21:2e:ff:ff:00:c4:9a)
    Extended Source: EnergyMi_ff:fe:e9:91:86 (d0:cf:5e:ff:fe:e9:91:86)
    ZigBee Security Header
    Command Frame: Route Record
        Command Identifier: Route Record (0x05)
        Relay Count: 1
        Relay Device 1: 0xc9fa[Tuin linksvoor 3]

الآن يرسل Tuin linksvoor 2 ردًا على البث network address request ونجح ، لكن APS ACK من deCONZ لم يصل أبدًا إلى Tuin linksvoor 2 ، لأنه انخفض بمقدار houtlamp 2 . لذلك يتم إعادة إرسالها عدة مرات قبل الاستسلام. سيكون لذلك فرصة جيدة لإفساد Tuin linksvoor 2 .

No. Time    Source  Transmit Dev    Receive Dev Destination Disable Default Response    Info
246199  10h 29m  1.496384s  Tuin linksvoor 2    Tuin linksvoor 3    DeConz  DeConz      Network Address Response, Status: Success, Address: EnergyMi_ff:fe:e9:91:86 = 0x0ea5
246201  10h 29m  1.502056s  DeConz  DeConz  HK houtlamp 2   Tuin linksvoor 2        APS: Ack, Dst Endpt: 0, Src Endpt: 0

Conbee 1 + أحدث fw + .74 لا يلعب 100٪.
حصلت على بعض الضربات / الإخفاقات. يبدو أنه يعمل بشكل أفضل مع .73 بالنسبة لي ، ولكن ليس بنسبة 100٪.

نعود للوحة الرسم. لا يزال غير مقبول بنسبة 100٪ مع الإصدار التجريبي 1 Conbee 1 fw.

بعد يومين من التشغيل باستخدام .74 و 26340500 على Conbee 1 على Tradfir E14 مع البرنامج الثابت 1.2.221 ، يمكن الإبلاغ عما يلي:

أصبح ضوء ايكيا أكثر استقرارًا من حيث التسرب من الشبكة على الرغم من أنني لم يكن لدي سوى لمبة واحدة ضاعت في 4 أيام. لقد اكتشفت أيضًا أنه إذا كنت تشدد على الجحيم من شبكة zigbee التي تديرها deconz والتي تعمل على E14 fw 1.2.221. قمت بتشغيل نص برمجي يتلاشى عن طريق إرسال طلبات فردية مع bri متغير كل ثانية. بهذه الطريقة فقدت 4 لمبات بسرعة كبيرة. لكن من يريد ذلك على أي حال ؛)

لا يزال بدون حل:
المشكلة والقلق الذي لا يزال لدي هو أن Tradfri FW 2.3.x لا يعمل بشكل جيد ، أو لم يتم تنفيذه بشكل جيد لاستخدامه مع deconz. من الجيد البقاء في tradfri fw 1.2.x وعدم الذهاب إلى zigbee 3.0. ولكن ستكون هناك نقطة زمنية لا يمكن تجنبها. أو لمبات حديثة بعد الآن أخشى.
اكتشفت أن مجموعة من 2 إلى 3 لمبات لا تظهر أن المشكلة سيئة للغاية كمجموعة من 4-8 لمبات.
لقد أبلغت عن مكتشفاتي هنا وأنا سعيد وشكر إذا تم التقاطها. حاولت رفع الوعي هنا https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2518
حيث يمكنني إعادة إنتاج هذه المشكلة ببساطة عن طريق وميض كل مصباحي إلى 2.3.x وآمل أن تتمكن من القيام بذلك أيضًا.

الخلاصة - يحدث فرقًا حول البرامج الثابتة tradfri المستخدمة والتي نتحدث عنها. هناك فرق كبير في قابلية الاستخدام وإصدار الخبرة والتشغيل مع deconz. بينما من المرجح أن يكون 1.2.x fws أقدم ويعمل مثل السحر بجانب المتسربين المعروفين ، فإن 2.3.x لا يفقد قابلية الاستخدام كما هو موضح في المشكلة المثارة. لا أستطيع أن أتخيل أنني الوحيد الذي يواجه هذا الاختلاف في FWs.

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

هل تم إصلاح البرامج الثابتة Conbee II الآن؟ لقد رأيت Conbee I فقط في الإصدار. بالمناسبة شكرا لكم جميعا لعملكم الشاق.

يحدث هذا مرة أخرى بسبب عدم قيام deCONZ بالتقاط سجل المسار كطريق جديد.

djwlindenaar اتضح أنني الملوم هنا ، لقد تحققت من تعليمات كود تسجيل المسار في مستودع المكدس (ConBee I و RaspBee I). في 2018 ، أضفت aa "fix" (أو اعتقدت ذلك) لمشكلة مماثلة أدت للتو إلى تعطيل تحديث عنوان القفزة التالية في سجل مسار وارد.

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

أعدت هذا الآن ، لذا يجب أن يقوم سجل المسار بتحديث المسار إلى المسار الأفضل.

أحب تلك الفقرة من مواصفات Zigbee:

قد يحتفظ جهاز توجيه ZigBee أو منسق ZigBee بجدول توجيه. يتم عرض المعلومات التي يجب تخزينها في إدخال جدول توجيه ZigBee في الجدول 3-66. يعد تقادم إدخالات جدول التوجيه وسحبها من أجل إعادة المطالبة بمساحة الجدول من الإدخالات التي لم تعد قيد الاستخدام ممارسة موصى بها ؛ ومع ذلك ، فهو خارج نطاق هذه المواصفات.

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

لذا فقد تحققت من كيفية عملها في حالتنا. في مسارات مكدس Bitcloud Zigbee لها "معدل" مسار ، وهو في البداية 1.

1. في إرسال NWK الناجح ، يتم زيادة المعدل إذا كان أقل من الحد الأقصى
   (1 << 8) - 1 = 255
2. في إرسال NWK ناجح ، إذا تم الوصول إلى الحد الأقصى وهو 255 ، يتم "تطبيع" كافة إدخالات جدول التوجيه
   rate = (rate >> 1) + 1 (مقسومًا فعليًا على 2 ، بحد أدنى 1)
3. في حالة فشل إرسال NWK ، يتم تعيين معدل إدخال المسار ذي الصلة على النحو التالي:
   rate -= (rate / 2) > 0 ? rate / 2 : 1
4. في العديد من عمليات الإرسال الفاشلة ، يصبح المعدل 0 ويتم إزالة المسار

هذا يعني أن الارتباط العلوي سيتراجع على النحو التالي:

255  top rate
127  first failed transmission
63   ...
31
15
7
3
1
0    the record gets removed

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

ما يهمني هو النقطة (2) لأنه على سبيل المثال طريق جديد جدًا أو مسار غير مستخدم والذي غالبًا ما يتدهور بسبب العقد عالية الأداء غير المرتبطة تمامًا مع الروابط الجيدة ، على سبيل المثال مصباح Philips Hue الذي يتم استقصائه كل بضع ثوان الزناد (2) في كثير من الأحيان يضرب ذلك بعدد الأضواء في شبكة كبيرة. ناهيك عن تحديثات OTA النشطة.

أعتقد أنه من الآمن تغيير (2) عدم تدهور (تطبيع) جميع إدخالات المسار ولكن فقط المسار العلوي 255 المرتبط بالإرسال الناجح. يجب أن يمنع هذا فقدان المسارات التي كانت تعمل بشكل جيد ولكن لم يتم استخدامها كثيرًا وتمت إزالتها عند أول إرسال فاشل NWK.

سأبني برنامجًا ثابتًا جديدًا مع هذه التغييرات غدًا ، ومن المحتمل أن ينطبق نفس الشيء أيضًا على ConBee II.

أعدت هذا الآن ، لذا يجب أن يقوم سجل المسار بتحديث المسار إلى المسار الأفضل.

حسنا يبدو جيدا. أنا أتطلع إلى الاختبار!

أحب تلك الفقرة من مواصفات Zigbee:

نعم ، أعتقد أن هذا النوع من التحديد يمنحنا صعوبة في جعل جميع البائعين يتعايشون بشكل جيد. :ابتسامة:

في مسارات مكدس Bitcloud Zigbee لها "معدل" مسار ، وهو في البداية 1.

لا أفهم حقًا المنطق الكامن وراء القاعدة 2. إنها تبدو نوعًا من نسخة الرجل الفقير من الشيخوخة. وهو ما يعمل جيدًا إذا كانت جميع العقد ترى قدرًا مشابهًا من حركة المرور ، ولكن في الواقع ، إذا كانت غير متوازنة (وهو ما أعتقد أنه شائع جدًا) ، فسوف تسوء.
لقد لاحظت أن ZStack يستخدم حقلًا فعليًا expiryTime في جدول التوجيه ، بجانب status بايت.

3. On a failed NWK transmission the rate of the related route entry is set as:

كيف يعمل هذا في الواقع؟
إذا لم أكن مخطئًا ، فإن فشل إرسال NWK يعني في الواقع الخطوة التالية فقط ، نظرًا لأن NWK يتحقق فقط من 802.15.4 MAC ACK. لذا للتحقق مما إذا كان الإرسال من طرف إلى طرف على ما يرام ، يجب أن نعتمد على APS ack. هل هذا صحيح؟ هل تعمل بهذه الطريقة في BitCloud؟
أيضًا: إذا لم يتم تعيين بت طلب ack في طبقة APS ، فهل يعتبر ذلك إرسالًا ناجحًا (نظرًا لعدم توقع ack) وهل هذا يزيد "معدل" إدخال المسار هذا؟ لأنه إذا كان الأمر كذلك ، فقد نطلق النار على أنفسنا من خلال عدم طلب ACK لطبقة APS طوال الوقت.

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

إصدار البرنامج الثابت 0x26350500 لـ ConBee I و RaspBee I متاح للاختبار.

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_Rpi_0x26350500.bin.GCF

• مثل 0x26340500 ، يتم معالجة جميع أخطاء مسار حالة NWK
• إصلاح تدهور المسار غير العادل (انظر النقطة 2. في https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment-596142584)
• إصلاح سجلات الطريق لم يحدّث الخطوة التالية من المسار ، لاحظ أن هذا سيعمل الآن ولكن فقط إذا كانت تكلفة المسار الحالي أعلى عند تسجيل المسار
• إصلاح طلبات APS الفاشلة مع تمكين APS ACK لا يؤدي إلى تدهور المسار

أنا الآن أبحث في كود ConBee II لمعرفة ما إذا كان يمكن تطبيق هذه الإصلاحات وأين. استبعاد 0x26520700 و 0x26530700 واستناد ذلك إلى 0x264a0700 الحالية المستقرة.

لا أفهم حقًا المنطق الكامن وراء القاعدة 2. إنها تبدو نوعًا من نسخة الرجل الفقير من الشيخوخة. وهو ما يعمل جيدًا إذا كانت جميع العقد ترى قدرًا مشابهًا من حركة المرور ، ولكن في الواقع ، إذا كانت غير متوازنة (وهو ما أعتقد أنه شائع جدًا) ، فسوف تسوء.
لقد لاحظت أن ZStack يستخدم حقل expiryTime الفعلي في جدول التوجيه ، بجوار بايت الحالة.

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

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

يبدو أن هذا هو الحال ، بل إن سوء تصرف أجهزة التوجيه ، التي لا ترسل أوامر حالة NWK مع فشل المسار ، يمكن أن تبقي طريقًا ميتًا على قيد الحياة. تم إصلاح هذا الآن في 0x26350500 ولكنه يعتمد على أوامر APS ACK الممكنة. يجب أن يكون الأمر جيدًا ويمكن التحكم فيه بواسطة deCONz والمكوِّن الإضافي REST-API.

إصدار البرنامج الثابت 0x26350500 لـ ConBee I و RaspBee I متاح للاختبار.

تومض ، الآن الاختبار.

تم إصلاح هذا الآن في 0x26350500 ولكنه يعتمد على أوامر APS ACK الممكنة.

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

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

اعتقدت الشيء نفسه ، هذا ما يحدث في هذه الحالة:

• إرسال NWK MAC ACK إيجابي للإرسال rate + 1
• ليس هناك APS ACK rate = rate / 4

لذلك ينخفض ​​السعر بسرعة إلى حد ما ، وقد يكون شديد العدوانية قليلاً و rate / 2 كافٍ ، لكن دعنا نرى كيف يعمل في الممارسة.

لطيف. سأقوم بتشغيله وتقديم تقرير.

حاليًا ، يؤكد الاختبار أيضًا عن طريق إرسال رسائل أحادية الإرسال (OnOffwithLevel) إلى ضوء بعيد جدًا في الشبكة ، كل بضع ثوانٍ.

بالمناسبة ، قمت أيضًا بتغيير رمز المكون الإضافي الباقي لطلب APS ACK في جميع الرسائل.

أنا أقوم بتشغيل Deconz على Rpi 3B + باستخدام Home Assistant
يعمل حاليًا 2.05.75 مع Conbee I و 26330500

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

شيء غريب هنا:
_ يمكنني تشغيل المفتاح عند تمكين مجموعة Deconz بدلاً من التبديل الفردي.

19: 23: 58: 979 تأخير إرسال طلب 57 dt 0 مللي ثانية إلى 0x000D6FFFFEB1C9FF ، ep: 0x01 الكتلة: 0x0004 onAir: 1
19:24: 15: 744 القناة الحالية 25
19: 24: 15: 776 جهاز TTL 3920 s أعلام: 0x7
19:24: 46: 764 0x000D6FFFFEB1C9FF خطأ APSDE-DATA. تأكيد: 0xA7 في المهمة
19: 25: 10: 547 0x000D6FFFFEB1C9FF خطأ APSDE-DATA. تأكيد: 0xA7 في المهمة
19:25: 15: 749 القناة الحالية 25
19: 25: 15: 782 جهاز TTL 3860 s أعلام: 0x7
19: 25: 33: 885 0x000D6FFFFEB1C9FF خطأ APSDE-DATA. تأكيد: 0xA7 في المهمة
19: 25: 49: 411 0x000D6FFFFEB1C9FF خطأ APSDE-DATA. تأكيد: 0xA7 في المهمة
19: 26: 12: 765 0x000D6FFFFEB1C9FF خطأ APSDE-DATA. تأكيد: 0xA7 في المهمة
19: 26: 12: 765 كحد أقصى أخطاء الإرسال للعقدة 0x000D6FFFFEB1C9FF ، آخر مرة شوهدها الجيران 25 ثانية
19:26: 15: 742 القناة الحالية 25
19: 26: 15: 774 أعلام جهاز TTL 3800 s: 0x7
19: 26: 48: 221 0x000D6FFFFEB1C9FF خطأ APSDE-DATA. تأكيد: 0xA7 في المهمة
19:26: 48: 221 كحد أقصى أخطاء الإرسال للعقدة 0x000D6FFFFEB1C9FF ، آخر مرة شوهدها الجيران 60 ثانية
19: 27: 03: 845 حالة العقدة المحفوظة في 9 مللي ثانية
19: 27: 33: 634 مزامنة () في 29789 مللي ثانية

أحدث الإصلاحات في 26350500 ...

djwlindenaar أنا

حتى الان جيدة جدا. أستطيع أن أرى ديكونز وهي تغير المسارات بسعادة. :ابتسامة:

أحدث الإصلاحات في 26350500 ...

آسف ، أخطأت في قراءة إصدار مهاجم.
أريد المساعدة في الاختبار ، باستخدام الوظيفة الإضافية الرسمية لـ Home Assistant Deconz ، لست متأكدًا من كيفية تحديث هذا البرنامج إلى برنامج بيتا الثابت. (التحديثات الرسمية هي OTA)

عزيزي manup ، أي حالة في Conbee ii fw update؟

manup ، يبدو أنه لا يوجد أي إجراء على Many-to-One Route Failure (0x0c) . أتوقع أن تقوم deCONZ بعمل MTORR مرة أخرى (ما لم يكن أحدها قيد التقدم بالفعل). أحصل على هذه الرسائل بانتظام.

Command Frame: Network Status
    Command Identifier: Network Status (0x03)
    Status Code: Many-to-One Route Failure (0x0c)
    Destination: 0x499e[Tuin rechtsachter 2]

manup ، يبدو أن route record لم يتم الاستيلاء عليه دائمًا بواسطة deCONZ. فمثلا:

No.                Time               Source             Transmit Dev       Receive Dev        Destination        Disable Default Response              Acknowledgement Request               Info
700766             13h 27m 35.628249s Tuin linksvoor 2   Tuin linksvoor 2   DeConz             DeConz                                                   Route Record, Dst: 0x0000
700784             13h 27m 39.591343s DeConz             DeConz             WC lamp            Tuin linksvoor 2   True               True               ZCL Level Control: Move to Level with OnOff, Seq: 162
700786             13h 27m 39.597002s DeConz             WC lamp            Tuin linksvoor 1   Tuin linksvoor 2   True               True               ZCL Level Control: Move to Level with OnOff, Seq: 162
700788             13h 27m 39.600699s DeConz             Tuin linksvoor 1   Tuin linksvoor 2   Tuin linksvoor 2   True               True               ZCL Level Control: Move to Level with OnOff, Seq: 162

الضوء Tuin linksvoor 2 يرسل مباشرة إلى deCONZ ، لكن المسار من deCONZ يمر عبر قفزات Sevaral ...
سيكون من المفيد إذا كان بإمكانك إعطاء نظرة ثاقبة لعملية اتخاذ القرار في deCONZ إلى نعم / لا قبول المسار من الرسالة route record .

--- حررت العناصر أدناه ، لأنه كان هناك خلل في تفكيري. الآن نأمل ألا: غمزة: -

بعد قولي هذا ، فإن المسار الذي يستخدمه deCONZ هو في الواقع أكثر موثوقية من الاتصال المباشر بـ Tuin linksvoor 2 . دفعني هذا إلى التساؤل والنظر في التوجيه من متعدد إلى واحد. أفكر في أنه ربما تكون قوة الإرسال لـ Raspbee ليست مثالية ...
هذا هو تفكيري:

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

هناك نقطة ذات صلة لاحظتها وهي أن شركة deCONZ تبدو متفائلة (جدًا) بشأن التكلفة الواردة في جدول مسارها. عندما يرسل Tuin linksvoor 2 رسالة إلى deCONZ مباشرة ، فإنه يحتاج إلى الكثير من المحاولات ، طوال الوقت. الآن إذا نظرت في جدول التوجيه ، أرى ما يلي ، ولا أتوقع صعوبة في الإرسال بتكلفة واردة قدرها 4. لاحظ أن جميع العناصر الموجودة في جدول التوجيه لها تكلفة واردة أقل بكثير من التكلفة الصادرة.

Link 4
    Address: 0x0ea5[Tuin linksvoor 2]
    .... .100 = Incoming Cost: 4
    .111 .... = Outgoing Cost: 7

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

القائمة الإجمالية من رسالة حالة ارتباط deCONZ:

Command Frame: Link Status
    Command Identifier: Link Status (0x08)
    .1.. .... = Last Frame: True
    ..1. .... = First Frame: True
    ...1 0010 = Link Status Count: 18
    Link 1
        Address: 0x0118[Buiten - R schuur]
        .... .011 = Incoming Cost: 3
        .111 .... = Outgoing Cost: 7
    Link 2
        Address: 0x0143[HK stalamp]
        .... .010 = Incoming Cost: 2
        .101 .... = Outgoing Cost: 5
    Link 3
        Address: 0x05b5[HK houtlamp 2]
        .... .010 = Incoming Cost: 2
        .101 .... = Outgoing Cost: 5
    Link 4
        Address: 0x0ea5[Tuin linksvoor 2]
        .... .100 = Incoming Cost: 4
        .111 .... = Outgoing Cost: 7
    Link 5
        Address: 0x1ad3[HK plafond ledstrip]
        .... .010 = Incoming Cost: 2
        .001 .... = Outgoing Cost: 1
    Link 6
        Address: 0x1ff6[Tuin linksvoor 1]
        .... .011 = Incoming Cost: 3
        .111 .... = Outgoing Cost: 7
    Link 7
        Address: 0x4b4d[Keuken mid]
        .... .011 = Incoming Cost: 3
        .111 .... = Outgoing Cost: 7
    Link 8
        Address: 0x5693[Keuken Rechts]
        .... .011 = Incoming Cost: 3
        .111 .... = Outgoing Cost: 7
    Link 9
        Address: 0x68c4[WC lamp]
        .... .011 = Incoming Cost: 3
        .111 .... = Outgoing Cost: 7
    Link 10
        Address: 0x6c35[Buiten - L schuur]
        .... .011 = Incoming Cost: 3
        .111 .... = Outgoing Cost: 7
    Link 11
        Address: 0x731e[Kerstverlichting]
        .... .011 = Incoming Cost: 3
        .011 .... = Outgoing Cost: 3
    Link 12
        Address: 0x7d2a[0x7d2a]
        .... .011 = Incoming Cost: 3
        .101 .... = Outgoing Cost: 5
    Link 13
        Address: 0xa3f5[HK zoutlamp]
        .... .010 = Incoming Cost: 2
        .001 .... = Outgoing Cost: 1
    Link 14
        Address: 0xc7bc[Hal lamp]
        .... .011 = Incoming Cost: 3
        .111 .... = Outgoing Cost: 7
    Link 15
        Address: 0xc9fa[Tuin linksvoor 3]
        .... .011 = Incoming Cost: 3
        .111 .... = Outgoing Cost: 7
    Link 16
        Address: 0xd6b7[Zolder Noord Lamp]
        .... .010 = Incoming Cost: 2
        .101 .... = Outgoing Cost: 5
    Link 17
        Address: 0xde81[On/Off light 36]
        .... .010 = Incoming Cost: 2
        .001 .... = Outgoing Cost: 1
    Link 18
        Address: 0xefd5[Zoldertrap Lamp]
        .... .010 = Incoming Cost: 2
        .001 .... = Outgoing Cost: 1

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

سأقوم بنشر التحديثات هنا بمجرد توفرها.

تحديث: ما زال قويا!

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

(آمل ألا أحس به الآن)

لاحظ أنني قمت بتغيير المكون الإضافي REST لطلب APS ack لجميع الطلبات.

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

نأمل أن يتم تأكيد ذلك من قبل الآخرين أو تحديد النتائج.

أقوم بتشغيل Conbee 1 مع FW 26350500 و Deconz 2.05.75.
هذه تجربتي في الأسابيع الماضية

• يعمل بشكل أفضل ولكن ليس بنسبة 100٪
• بعض من لمبة IKEA E27 TRÅDFRI الخاصة بي E27 WS opal 980lm مع fw 2.3.007 تفشل أحيانًا في الرد على أوامر OFF
• يمكنني فقط محاولة إيقاف تشغيلها مرة أخرى وعادة ما تعمل (لا حاجة لدورة الطاقة)

Djwlindenaar لطيف! هل تم تضمين إصلاح APS الخاص بك لـ REST API في الإصدار .75؟ فقط لأعرف ما إذا كان ذلك يمكن أن يفسر بعض الاختلافات في المشاركات السابقة ...

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

tubalainen ،

من المحتمل وجود مشكلة في سلوك إعادة المحاولة في deCONZ. سأحتاج إلى إجراء تجربة لذلك أو ربما يكون موجودًا بالفعل في سجلات الشم.

إذا كنت تستطيع الشم ، فإن شم هذه الظاهرة سيساعدك. يمكنني المساعدة في التحليل إذا لم تستطع.

ترقية شبكة الإنتاج الخاصة بي (RPi 3B + ، تمتد ، RaspBee) إلى 2.05.74 و 0x26340500 أمس. يبدو مستقرًا ، باستثناء المشكلات أدناه.
لست متأكدًا مما إذا كان مرتبطًا ، ولكن الطريق إلى وحدة التحكم في الستائر lumi.curtain الخاصة بي قد فقدت هذا الصباح. ستظل التقارير الصادرة عن وحدة التحكم تصل إلى البوابة. لن يتم استعادة المسار عند تدوير الطاقة لجهاز التحكم. اضطررت إلى فتح الشبكة ودورة طاقة وحدة التحكم ، قبل أن يصل المنسق إليها مرة أخرى.
أيضًا ، كان أحد صمامات المشعاع Eurotronic Spirit الخاص بي لا يمكن الوصول إليه بواسطة deCONZ بعد بدء تشغيل deCONZ ، مع استمرار إرسال التقارير. ركوب الدراجات الكهربائية أعادها TRV ، كالمعتاد.
لم تتح لي الفرصة لإجراء أي تحقيق عميق هذه المرة ، لكن كلا الجهازين كانا يمثلان مشكلة منذ البداية ، حيث ظهرت هذه الأعراض من حين لآخر. نفس الشيء بالنسبة للستائر الداخلية من ايكيا سأستمر في مراقبة الموقف وتقديم تقرير مرة أخرى إذا واجهت المزيد من المشكلات.

من الصعب جدًا تسجيل هذه المشكلات المتقطعة بشكل موضوعي ، لكن لدي انطباع بأن 0x26350500 قد أدخل تحسينات هنا. بصرف النظر عن الأجهزة المذكورة أعلاه ، فإن شبكتي مستقرة للغاية. لقد أصبحت بعض TRVs غير قابلة للوصول من البوابة ، ولكن في الغالب (فقط؟) بعد إعادة تشغيل deCONZ. لا أعتقد أن FYRTUR ولا وحدة التحكم في الستارة قد ذهبت إلى MIA خلال الأسابيع الثلاثة الماضية.

لاحظ أنني قمت بتغيير المكون الإضافي REST لطلب APS ack لجميع الطلبات.

لدي بالفعل APS Acks ممكَّنة في _Network Settings_ في واجهة المستخدم الرسومية ، لكنني لست متأكدًا مما إذا كان هذا ينطبق فقط على الرسائل المرسلة بواسطة واجهة المستخدم الرسومية ، أو أيضًا على المكون الإضافي REST API.

إذا كنت تريد التشغيل باستخدام طلب السحب أعلاه ، فيمكنك أيضًا التحقق من مفترقتي وإنشاء ما يلي: djwlindenaar / deconz-rest-plugin

ebaauw ، بقدر ما أستطيع أن أقول ، هذا ينطبق فقط على الأوامر المرسلة من واجهة المستخدم الرسومية

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

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

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

كما ذكرت ، كان لدي برنامج نصي يعمل لتغيير مستوى الضوء كل ثانيتين. التفكير في أن هذا قد يؤدي إلى تسريع مشكلات مصابيح ايكيا تبين أن هذا يعيد تعيين العداد d->idleLastActivity ، والذي يمنع تشغيل أي مهام خاملة. بما في ذلك تكوين تقارير السمات: rofl:

هل تقول أن مصابيح ايكيا تفقد ارتباطاتها وتكوين تقارير السمات بعد دورة الطاقة ؟!

يبدو أنه ... أليس كذلك ..؟

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

djwlindenaar ، لا ، لا أعتقد أنه ينبغي عليهم ذلك. معظم الأجهزة التي رأيتها تحتفظ بهذه الإعدادات في ذاكرة غير متقلبة. أفترض أن معيار ZigBee يترك مجالًا لأي من السلوكين.

بينما تعمل مصابيح ايكيا الخاصة بي بشكل أفضل الآن ، لسوء الحظ ، لا يستجيب أحد مستشعرات Xiaomi (مستشعر درجة الحرارة المستدير) بعد فترة. سأحاول جمع بعض الأدلة عن طريق الشم في الأيام القادمة.

أقوم بتشغيل Conbee 1 مع FW 26350500 و Deconz 2.05.75.
هذه تجربتي في الأسابيع الماضية

• يعمل بشكل أفضل ولكن ليس بنسبة 100٪
• بعض من لمبة IKEA E27 TRÅDFRI الخاصة بي E27 WS opal 980lm مع fw 2.3.007 تفشل أحيانًا في الرد على أوامر OFF
• يمكنني فقط محاولة إيقاف تشغيلها مرة أخرى وعادة ما تعمل (لا حاجة لدورة الطاقة)

tubalainen مرحبًا ، لقد لاحظت السلوك المختلف لـ IKEA مع البرامج الثابتة 2.3.x مقارنة بـ 1.2.x أيضًا. حاولت معالجته لكن لم أحصل على أي اهتمام. لقد خفضت مستوى المصابيح الخاصة بي إلى 1.2.x وهي تعمل بشكل رائع الآن. بتاريخ 2.3.x. لا يمكنك إيقاف التشغيل بعد إعادة تسجيل المشهد لفترة من الوقت. عادي على إيقاف العمل. سلوك غريب. ربما تريد الاختبار والمساهمة هنا. في صحتك https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2518

هل تقول أن مصابيح ايكيا تفقد ارتباطاتها وتكوين تقارير السمات بعد دورة الطاقة ؟!

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

سيتم تخفيضrealwax إلى 1.2.x على جميع مصابيح E27 الخاصة بي وإبلاغك بذلك. (يستغرق بعض الوقت :)).

بالأمس ، لم ينطفئ مصباحان E27 (مع 2.3x FW) أثناء التسلسل الصباحي.

tubalainen هل تستخدم أوامر المجموعة أو أوامر الإرسال الأحادي؟ (على سبيل المثال ، عبر REST api ، حدد الحالة عبر / groups / أو / lights /)

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

tubalainen هل تستخدم أوامر المجموعة أو أوامر الإرسال الأحادي؟ (على سبيل المثال ، عبر REST api ، حدد الحالة عبر / groups / أو / lights /)

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

يمكنني استخدام Home Assistant و RESt api. لا أعرف ماذا يفعل Home Assistant ...

في حالتي هو iobroker مع المكونات الإضافية deconz و Phoscon ... لذا بقية API. تظهر المشكلات عند استخدام igroups. يؤدي استدعاء مشهد المجموعة إلى عدم إمكانية إيقاف تشغيل المجموعة أو تغييرها بسرعة إلى إعدادات مشهد المجموعة الأخرى أو إيقاف تشغيلها بشكل صحيح ، خاصة في غضون ما يصل إلى 15 ثانية بعد استدعاء المشهد. يبدو أن deconz مشغول بالأمر السابق ، أو تجميد لمبات 2.3.x fw (وهو ما أشك فيه). لا يمكن تصحيح الأخطاء على مستوى zigbee حتى الآن للحصول على فهم أفضل. هل ميزة التجميع الخاصة بـ deconz هي طبقة افتراضية تُترجم في أوامر uni cast أو تتم عبر خيارات التجميع المتاحة في gui / zigbee؟ خلاصة القول إنني أستخدم وظيفة المجموعة المضمنة وإلا سأحتاج إلى إنشاء هذه الطبقة الافتراضية في iobroker وليس هناك سبب لأن ميزة التجميع جيدة. إذن إذا كان هذا هو التجميع ... ما هو الفرق حيث يبدو 100٪ مع fw 1.2.x وليس مع 2.3.x. ما الذي تغير؟ هل هو zigbee 2 لماذا يتصرفون بشكل مختلف.

tubalainen نعم هذا يتطلب الكثير من العمل حيث قد تحتاج إلى إعادة التشغيل من وقت لآخر أو تقريب بعض المصابيح. فعلت ذلك مرتين مع 20 e14 tradfri. يجب أن ترى تحسنًا كبيرًا. هل تلاحظ أن المصابيح الخاصة بك مع 2.3..x لا تعمل بشكل ناعم. (تتلاشى) بعد الآن و 1.2.x تفعل؟

لكن الأصابع عبرت أن المزيد يمكن إعادة إنتاجه ، لذا فإن ikeas fw 2.3.x سيصبح قابلاً للتشغيل في deconz حيث ستكون هناك نقطة زمنية نحتاج إلى الترقية. أو استبدل المصابيح. على الرغم من أن zigbee 2 سيكون لطيفًا أيضًا.

شكرا لكم جميعا على جهودكم!

realwaxdjwlindenaarmanup

الليلة الماضية لم ينطفئ ضوء واحد كما ينبغي (IKEA E27 مع fw 2.3.x). لقد اختبرت تغيير السطوع على هذا الضوء الذي لم ينطفئ وتغير على الفور إلى إعداد السطوع الذي اخترته. بعد لحظات من تغيير السطوع ، استجاب الضوء فجأة جيدًا لأمر إيقاف التشغيل.

لقد غيرت الآن شخصيًا جميع الأتمتة الخاصة بي في Home Assistant لتغيير السطوع أولاً ، وانتظر لمدة ثانيتين ثم أرسل أمر إيقاف التشغيل.

حتى الآن معدل نجاح 100٪.

آمل أن يكون هذا دليلًا على التحقيق.

تحرير: لا تزال الأضواء هي الأبعد عن التنسيق (العصا Conbee) التي تفشل في الإطفاء. (الأضواء التي يجب أن تتشابك بسبب طبيعة نطاق التردد)

مرحبا يا اصدقاء!

أردت فقط أن أتطرق إلى مشاكلي ...
بعد وجود مشكلات في الاستقرار مع عصا ConBee II ، تحققت من إصدار البرنامج الثابت. كان 26530700. ثم خفضت إلى 264a0700 ، وبعد ذلك لا يمكن لأي تطبيق رؤية العصا. لقد جربت HomeAssistant و deCONZ. يحدد نظام التشغيل المضيف العصا OK ويعمل GCFFlasher.

مرحبا يا اصدقاء!

أردت فقط أن أتطرق إلى مشاكلي ...
بعد وجود مشكلات في الاستقرار مع عصا ConBee II ، تحققت من إصدار البرنامج الثابت. كان 26530700. ثم خفضت إلى 264a0700 ، وبعد ذلك لا يمكن لأي تطبيق رؤية العصا. لقد جربت HomeAssistant و deCONZ. يحدد نظام التشغيل المضيف العصا OK ويعمل GCFFlasher.

بعد تخفيض التصنيف إلى 26490700 ، يبدو أن كل شيء يعمل مرة أخرى ... شبكة

أي تحديثات؟ أريد حقًا تبديل منزلي بالكامل إلى Conbee II الخاص بي ، لكن الوضع غير مستقر في الوقت الحالي. صبغة تعمل بشكل مثالي ، Conbee II ليس كثيرًا 🥺

تجربتي مع أحدث إصدار من deCONZ .75 مع RaspBee FW 0x26350500 جيدة جدًا حتى الآن.

أجهزتي:
مصابيح 4xTradfri 980lu WS - FW 2.3.007
17 مصابيح xTradfri 1000lu WS - FW 2.0.023
3xTradfri المقابس - FW 2.0.022
أجهزة التحكم عن بعد 3xTradfri Round E1810 - FW 2.3.014
4xAqara THP مجسات

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

رأيت ضوءًا واحدًا لا يستجيب هذا الصباح. يظهر الاتصال الأخير أدناه.

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

أعتقد أن deConz يمكن أن تنظر في الطلب المعترف به بمجرد وصول الاستجابة المقابلة وتجنب تقديم طلب آخر. حق؟ هل توجد واجهة برمجة تطبيقات للمكوِّن الإضافي يمكن استدعاؤها لإلغاء الطلب؟ @استرجل؟

لاحظ أن هذا الخطأ المحدد يعمل أيضًا من خلال عدم طلب APS ACK لهذه الطلبات ، وهو الإعداد الافتراضي في المكون الإضافي REST API الحالي.

No.               Time              Source            Transmit Dev      Receive Dev       Destination       Disable Default Response            Acknowledgement Request             Info
74174             2h 48m 12.832154s DeConz            DeConz            HK houtlamp 2     HK houtlamp 2     True              True              ZCL Groups: Get Group Membership, Seq: 32
74176             2h 48m 12.841977s HK houtlamp 2     HK houtlamp 2     DeConz            DeConz                                                Route Record, Dst: 0x0000
74178             2h 48m 12.847098s HK houtlamp 2     HK houtlamp 2     DeConz            DeConz                                                Route Record, Dst: 0x0000
74180             2h 48m 12.890302s HK houtlamp 2     HK houtlamp 2     DeConz            DeConz            True              True              ZCL Groups: Get Group Membership Response, Seq: 32
74182             2h 48m 12.896074s DeConz            DeConz            HK houtlamp 2     HK houtlamp 2                       False             APS: Ack, Dst Endpt: 1, Src Endpt: 1
74183             2h 48m 12.899402s DeConz            DeConz            HK houtlamp 2     HK houtlamp 2                       False             APS: Ack, Dst Endpt: 1, Src Endpt: 1
74184             2h 48m 12.902460s HK houtlamp 2     HK houtlamp 2     DeConz            DeConz                              False             APS: Ack, Dst Endpt: 1, Src Endpt: 1
74185             2h 48m 12.904330s DeConz            DeConz            HK houtlamp 2     HK houtlamp 2                       False             APS: Ack, Dst Endpt: 1, Src Endpt: 1
74190             2h 48m 14.186599s DeConz            DeConz            HK houtlamp 2     HK houtlamp 2     True              True              ZCL Groups: Get Group Membership, Seq: 32
76346             2h 52m 41.998416s DeConz            DeConz            HK houtlamp 2     HK houtlamp 2                       True              Link Quality Request
76354             2h 52m 43.668838s DeConz            DeConz            HK houtlamp 2     HK houtlamp 2                       True              Link Quality Request
202171            7h 39m 10.905361s HK houtlamp 2     HK houtlamp 2     Broadcast         Broadcast                           False             Device Announcement, Nwk Addr: 0x05b5, Ext Addr: SiliconL_ff:fe:c5:2c:7d

يعمل v2.05.75 مع 0x26350500 لبضعة أسابيع الآن. يبدو أكثر استقرارًا قليلاً من الإصدارات السابقة ، لكنني ما زلت أفقد أحيانًا الطريق إلى Eurotronic Spirit TRVs ، و Fyrtur الستارة الخاصة بي ، ووحدة التحكم الستار Xiaomi lumi.curtain . هذا الأخير هو جهاز توجيه. الآخرون عبارة عن أجهزة طرفية. تحتوي جميع TRVs على نفس إصدار الأجهزة / البرامج الثابتة ، لكن بعضها يستخدم MIA أكثر من البعض الآخر. الأعراض متسقة: يستمر الجهاز في إرسال التقارير إلى المنسق ، لكن الأوامر الصادرة من المنسق لا تؤدي إلا إلى عدم الرد _Route Request_.

يقوم حاليًا باستنشاق وتحليل حركة المرور لـ TRV التي تختفي في أغلب الأحيان. تصل التقارير إلى المنسق في ثلاث مراحل ، باستخدام مصباحي Hue على طول الطريق. لقد التقطت أيضًا _ Data Request_ من TRV إلى أول ضوء في الطريق ، لذلك يبدو TRV سعيدًا لأن هذا هو والدها. طلبات واصف المطابقة من TRV لمجموعة OTAU لا يتم الرد عليها. يقوم الوالد بالإبلاغ عن الضوء التالي في _Link Status_ ، ولكن ليس TRV (لأنه جهاز نهائي؟).

تعرض رسائل _Link Quality Response_ جدول الجوار المكون من 20 إدخالاً ، ولكن TRV ليس من بينها. مستشعر باب Xiaomi (الذي كان ثابتًا إلى الأبد) هو. ومن الغريب أن يكون المنسق كذلك ، ومع ذلك تم نقل التقرير من TRV إلى المنسق عبر جهاز توجيه آخر (وهو موجود أيضًا في جدول الجوار).
حسنًا ، تم تضمين المنسق الآن أيضًا في _Link Status_ والتقرير التالي من TRV يتم إرساله مباشرةً إلى المنسق.

تدوير الطاقة TRV. يرسل TRV طلب _Data MAC إلى الوالد (السابق) ؛ يستجيب الموجه بـ _Rejoin Response_Meru عنوان NWK القديم لـ TRV كعنوان جديد. ثم تبث قناة TRV _Device Announcement_ (MAC أحادي الإرسال إلى الوالد ؛ يقوم الأصل بإعادة التوجيه كبث MAC). يرسل TRV _End Device Timeout Request_ إلى الوالد ؛ يرسل الوالد _Update Device_ إلى المنسق لإعلامه بأن TRV قد انضم بشكل آمن. يرسل الوالد الآن أيضًا _Route Reply_ إلى _Route Request_ الخاص بالمنسق. في تسلسل _Link Quality Response_ التالي ، يتم تضمين TRV.

سأستمر في تشغيل الشم ، وآمل أن ألتقط اللحظة التي يختفي فيها TRV مرة أخرى.

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

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

لقد وجدت مشكلة أخرى في سلوك التوجيه الخاص بـ deConz.

في هذه الحالة ، يحاول deConz توجيه الرسالة إلى Hal lamp عبر Tuin linksvoor 3 . لكن بالنظر إلى التقرير Link Status من Tuin linksvoor 3 ، لا يعرف عن Hal lamp . ومن الواضح أيضًا أنه لا يعرف كيفية الوصول إليه من خلال التوجيه. بالطبع يجب أن يتصرف هذا الضوء (ايكيا) بنفسه ويستجيب برسالة فشل ، لكنه لا يفعل ولا يمكننا تغيير ذلك.
ومع ذلك ، خلص deConz إلى أن Hal lamp هو كائن زومبي دون أي محاولة للعثور على مسار جديد لهذا الضوء. لست متأكدًا من كيفية تفاعل ذلك مع كود التوجيه (الجديد) ، ولكن بطريقة ما لم يفسد هذا المسار بالسرعة الكافية لمنع وضع علامة عليه كزومبي. (راجع للشغل ليس كذلك حقًا ، انظر التالي ...)

تسبب هذا في مشكلة مؤقتة حلت نفسها بعد بضع دقائق (وهو بالطبع غير مقبول تمامًا). لأن Hal lamp قرر إرسال تقرير السمة ، والذي لا يتلقى ACK لـ APS ، وبالتالي يبدأ عملية Route Request . الآن فقط ، بعد اكتمال ذلك ، تغير deConz مسارها إلى Hal lamp ويستأنف الاتصال كالمعتاد.

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

No.                Time               Source             Transmit Dev       Receive Dev        Destination        Disable Default R  Acknowledgement Request               Info
392213             13h 31m 26.050526s Tuin linksvoor 3   Tuin linksvoor 3   Broadcast          Broadcast                                                Link Status
392241             13h 31m 26.182875s DeConz             DeConz             Tuin linksvoor 3   Hal lamp           True               True               ZCL Level Control: Move to Level with OnOff, Seq: 252

Command Frame: Link Status
    Command Identifier: Link Status (0x08)
    .1.. .... = Last Frame: True
    ..1. .... = First Frame: True
    ...1 0000 = Link Status Count: 16
    Link 1
        Address: 0x0000[DeConz]
        .... .111 = Incoming Cost: 7
        .100 .... = Outgoing Cost: 4
    Link 2
        Address: 0x0118[Buiten - R schuur]
        .... .111 = Incoming Cost: 7
        .111 .... = Outgoing Cost: 7
    Link 3
        Address: 0x0143[HK stalamp]
        .... .111 = Incoming Cost: 7
        .111 .... = Outgoing Cost: 7
    Link 4
        Address: 0x05b5[HK houtlamp 2]
        .... .111 = Incoming Cost: 7
        .101 .... = Outgoing Cost: 5
    Link 5
        Address: 0x0ea5[Tuin linksvoor 2]
        .... .011 = Incoming Cost: 3
        .001 .... = Outgoing Cost: 1
    Link 6
        Address: 0x1ff6[Tuin linksvoor 1]
        .... .011 = Incoming Cost: 3
        .011 .... = Outgoing Cost: 3
    Link 7
        Address: 0x23ec[Tuin linksachter 1]
        .... .111 = Incoming Cost: 7
        .111 .... = Outgoing Cost: 7
    Link 8
        Address: 0x2b9e[Bijkeuken]
        .... .111 = Incoming Cost: 7
        .111 .... = Outgoing Cost: 7
    Link 9
        Address: 0x325d[0x325d]
        .... .111 = Incoming Cost: 7
        .111 .... = Outgoing Cost: 7
    Link 10
        Address: 0x6339[Tuin rechtsvoor 3]
        .... .101 = Incoming Cost: 5
        .101 .... = Outgoing Cost: 5
    Link 11
        Address: 0x68c4[WC lamp]
        .... .111 = Incoming Cost: 7
        .111 .... = Outgoing Cost: 7
    Link 12
        Address: 0x731e[Kerstverlichting]
        .... .111 = Incoming Cost: 7
        .000 .... = Outgoing Cost: 0
    Link 13
        Address: 0x7d2a[HK houtlamp]
        .... .111 = Incoming Cost: 7
        .111 .... = Outgoing Cost: 7
    Link 14
        Address: 0xc520[Badkamer ledstrip]
        .... .111 = Incoming Cost: 7
        .101 .... = Outgoing Cost: 5
    Link 15
        Address: 0xca27[Tuin rechtsvoor 2]
        .... .101 = Incoming Cost: 5
        .101 .... = Outgoing Cost: 5
    Link 16
        Address: 0xd6b7[Zolder Noord Lamp]
        .... .111 = Incoming Cost: 7
        .000 .... = Outgoing Cost: 0

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

djwlindenaar عمل عظيم مرة أخرى. شكرا جزيلا! هل تشارك اكتشاف (اكتشافات) الأخطاء في IKEA FW مع ايكيا؟

djwlindenaar :

بالطبع يجب أن يتصرف هذا الضوء (ايكيا) بنفسه ويستجيب برسالة فشل ، لكنه لا يفعل ولا يمكننا تغيير ذلك.

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

ربما يكون الاتصال بمعامل السيليكون فكرة أفضل ، لأن هذا هو ما تُبنى عليه عناصر ايكيا. لست متأكدًا مما إذا كانت الأخطاء تنبع من رمز Ember أو تخصيص IKEA ...

djwlindenaar يمكنك أيضًا محاولة التواصل عبر reddit: https://www.reddit.com/user/TRADFRI إنهم نشيطون جدًا هناك.

manup أي أخبار عن البرامج الثابتة Conbee II؟

بعد الرجوع إلى إصدار سابق من البرامج الثابتة إلى 0x264a0700 لم يعد بإمكاني الاتصال بـ Conbee II. حاولت الرجوع إلى 0x264a0700 وبعض البرامج الثابتة القديمة أيضًا ، الوميض يعمل بشكل جيد ولكن لا يمكنه الاتصال. أي نصيحة حول كيفية إعادة تعيين عصا Conbee II؟

manup أي تحديثات؟ هل يجب أن أبحث عن شيء آخر غير deConz أم أن العمل جار لحل المشكلات؟ من فضلك أعط علامة على الحياة 🤗

أرغب فقط في تشغيل Conbee II مرة أخرى بعد تجربة البرنامج الثابت للاختبار ...

djwlindenaar أي تحديثات من جانبك؟ لا تزال شبكة مستقرة مع إصلاحاتك؟

من الجيد أن ترى أن علاقاتك العامة مدمجة بواسطة

djwlindenaar أي تحديثات من جانبك؟ لا تزال شبكة مستقرة مع إصلاحاتك؟

من الجيد أن ترى أن علاقاتك العامة مدمجة بواسطة

@ JBS5 أنا سعيد بالوضع المتوسط.

لقد تحسنت بشكل واضح لشبكتي. ومع ذلك ، ما زلت أرى الخلل في مصابيح ايكيا يربك deCONZ أحيانًا.

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

يبدو أن التغييرات التي تم إجراؤها على برنامج deCONZ الثابت تعمل على تحسين الموقف ، ولكن لا يزال هناك شيء يمكن إضافته لهذه المواقف. من المؤكد أن عدم وجود APS ACK يجب أن يؤدي على الفور إلى اكتشاف مسار جديد.

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

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

شكراdjwlindenaar.
نظرًا لأنه منذ فترة علقت

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

manup ؟

_ هو _ يجعلني أفكر في الابتعاد عن deCONZ لشبكتي المنزلية ...

djwlindenaar ، ما البدائل التي تفكر فيها؟ أنا حاليًا لست معجبًا باستقرار Conbee II.

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

manup ؟

_ هو _ يجعلني أفكر في الابتعاد عن deCONZ لشبكتي المنزلية ...

هل يقوم Zigbee2MQTT بعمل أفضل أم أنك لا تقصد ذلك بالبديل؟

بلى. هذا هو.

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

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

مرحبا سويا،

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

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26580700.bin.GCF

من المحتمل أن يكون هذا الإصدار جزءًا من إصدار deCONZ 2.05.76 القادم ، وسيتم رفع البرنامج الثابت ConBee I و RaspBee I الإصدار 0x26350500 ليتم تثبيته عن طريق زر التحديث.

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

manup لا يزال deCONZ غير متصل بـ ConBee II ، حتى بعد وميض البرنامج الثابت الجديد. كانت هذه المشكلة لفترة من الوقت.

manup حاولت وميضها عدة مرات ، لكن

Flash update failed, invalid CRC. Please try again.

14:29:06:105 query bootloader v1 ID after 5 ms
14:29:06:122 RX 60 bytes ASCII
R21B18 Bootloader
Vers: 2.05
build: Mar 22 2019
, 14:55:05
 after 22 ms
14:29:06:122 bootloader start after 22 ms
R21B18 Bootloader
Vers: 2.05
build: Mar 22 2019
14:29:06:124 GCF_ResetDeviceDone
14:29:06:125 bootloader v1 update firmware
flashing 160930 bytes: |==============================|
verify: .
Flash update failed, invalid CRC. Please try again.

هل هذا GCFFlasher 3.13؟

هذا هو السجل من التحديث الخاص بي:

GCFFlasher_internal -d /dev/ttyACM0 -f deCONZ_ConBeeII_0x26580700.bin.GCF 
GCFFlasher V3_13 (c) dresden elektronik ingenieurtechnik gmbh
Reboot device /dev/ttyACM0 (ConBee II)
deCONZ firmware version 26570700
R21B18 Bootloader
Vers: 2.05
build: Mar 11 2019
flashing 160930 bytes: |==============================|
verify: .
SUCCESS
Wait 10 seconds until application starts

نعم كان 3.13 ، إنه يعمل الآن لقد أعدت تشغيل النظام بالكامل. غريب ، مجرد إعادة تشغيل ConBee II لم ينجح ، لكن إعادة التشغيل تعمل ..

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

manup حتى أنني حاولت وميض البرامج الثابتة القديمة (إصدارات متعددة) ومعدل الباود 9600. كل ذلك أدى إلى نفس خطأ CRC.

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

سعيد لأنه يعمل الآن. لقد أجريت للتو مناقشة مع الكليات حول أداة تحميل التشغيل. كان الإصدار 2.05 من الدفعة الأولى من ConBee II في عام 2019 (حوالي 3500 قطعة) ، وهذا الإصدار صعب بعض الشيء في بعض الحالات. منذ يوليو 2019 ، نشحن 2.07 مع بعض الإصلاحات لمناولة المراقبة.

هناك محمل إقلاع جديد 3.x قيد التطوير وهو بالفعل جزء من RaspBee II ، ولديه طريقة تصميم وبروتوكول أكثر قوة لإصلاح مشكلات الإصدار 2.x.

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

مرحبا

تومض مع البرامج الثابتة الجديدة اليوم ، لكنني ما زلت أرى سجلات مثل:

0x000D6FFFFE540E7C خطأ APSDE-DATA. تأكيد: 0xA7 في المهمة

هل هذا مرتبط؟

يشير 0xA7 إلى أنه لم يتم توفير ACK APS في المكان الذي كان ينبغي أن يكون فيه. أعتقد أن ذلك قد يكون له أسباب متنوعة.

مرحبًا manup ،

أهلا مرة أخرى،

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

ما زلت أتلقى الكثير من الأخطاء مثل الخطأ الذي نشرته منذ 4 أيام.

عدد الكود
0xA7 29
0xAE 31
0xD0 1
0xE1 1
0xE9 14
إجمالي 76

لدي 26 جهازًا ينشر هذه الأخطاء اليوم ، يبدو أنها ساءت قليلاً مع 0x26580700

هل يمكن أن يخبرني أحد ما إذا كان هذا متعلقًا بمشكلة التوجيه هذه؟ أو يجب أن أفتح مشكلة مع مشكلتي

لاحظ أنه يبدو أنه يحدث فقط عند إرسال fx. "تشغيل" إلى ~ 20 مصباحًا في نفس الوقت "

مرحبًا manup ،

مرحبًا djwlindenaar ، نعم

مرحبًا djwlindenaar ، نعم

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

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

مرحبًا manup ،

مرحبًا djwlindenaar ، نعم

مرحبًا مانوب ، ربما أختطف هذا الموضوع ، لذا إذا كان الأمر كذلك ، يرجى تجاهل ذلك. لدي Conbee ii على Home Assistant وكان يعمل بشكل رائع حتى قبل شهر أو نحو ذلك. في هذه المرحلة ، ستصبح جميع مستشعرات Xiaomi الخاصة بي بمثابة أتمتة كسر غير موثوق بها. لدي بعض وحدات التحكم dresden fls-pp التي أمتلكها لبضع سنوات. هذه متصلة بشرائط LED وتستخدم للتخلي عن الشبكة بشكل متقطع مما يجبر على إعادة التشغيل لإعادة تشغيلها. أخيرًا أزلتهم جميعًا من شبكة Conbee الخاصة بي وعلى الفور أصبحت الشبكة بأكملها مستقرة. تركتها بضعة أيام ثم أعدت تقديم واحدة عملت لبضع ساعات ثم فشلت شبكة Zigbee الخاصة بي طوال الليل ولم أتمكن من إعادة تشغيل جميع المفاتيح / المستشعرات عبر الإنترنت حتى قمت بإيقاف تشغيل وحدة تحكم Dresden. لا توجد فكرة عن السبب ولكن بالنسبة لي ، فإن استخدام وحدات التحكم dresden يكسر شبكة zigbee الخاصة بي. أنا فقط مبتدئ في هذا الأمر ، لذا لست متأكدًا مما إذا كان هذا مفيدًا / ذي صلة ، لكنني كنت أبحث عن أي تعليقات حول هذا وحدثت في هذا الموضوع ، لذلك اعتقدت أنني سأضع تجربتي في المزيج فقط في حالة. في الوقت الحالي ، أقوم فقط بإزالتها من شبكتي - لا يستحق الصداع الذي كانوا يقدمونه لي!
في صحتك

مرحبًا djwlindenaar ، نعم

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

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

لقد قررت الانتقال إلى zigbee2mqtt نظرًا لمشاكل التوجيه (الأمر الأكثر إزعاجًا هو الحاجة إلى إعادة إقران Ikea / Xiaomi من حين لآخر). سوف أنشر نتائجي هنا في غضون بضعة أسابيع ...

بعد وميض البرامج الثابتة 0x26350500 على Conbee I الخاص بي (وتحديث deCONZ إلى 2.05.76) يوم الاثنين الماضي ، لسوء الحظ انقطع GU10 عن العمل.

في VNC يكون لونه رمادي قليلاً:

الفوسكون:

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

@ JBS5 ، لا أعتقد أنه من الضروري تشغيل أضواء دورة الطاقة بعد ترقية البرنامج الثابت (ما لم تكن معطلة قبل الترقية ، فلن يتم إحياءها بطريقة سحرية ...).
ربما يرجع ذلك إلى حقيقة أنه على الرغم من التحسن ، إلا أننا لسنا على دراية كاملة بمشكلات التوجيه ؛ انظر منشوراتي السابقة.

djwlindenaar شكرا. أنا أفهم.

لما يستحق ، لأنه نوع من نفس السلوك كما هو الحال مع البرامج الثابتة السابقة:

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

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

@ JBS5 ، نعم ، هذا يبدو وكأنه سلوك نموذجي. في الواقع لا حرج في ضوء GU10 هذا. إنها فقط أن deCONZ فقدت طريقها للتواصل معها مباشرة. بعد مرور بعض الوقت ، يتسبب هذا أيضًا في قطع اتصال أجهزته الطرفية نظرًا لعدم تلقيها أي تعليقات من deCONZ. أخيرًا ، مع حرمان GU10 من حزم الشبكة بشكل كافٍ ، فإنه يصبح غير متصل بالإنترنت بشكل حقيقي.

ربما في المرحلة التي لا يزال فيها يستجيب لأوامر المجموعة ، ستتمكن من تشغيل موجه آخر ، وهو أمر جيد على ما يبدو ، وسوف يتعافى GU10. هذا الموجه الآخر لا يلعب بشكل جيد ولا يستجيب deCONZ بشكل جيد للموقف.
لذلك لا تغضب من GU10 ؛)

مرحبًا djwlindenaar ، نعم

manup ، بالتأكيد ، أعتقد أن القضية الرئيسية لا تزال أن deCONZ لا تزال عنيدة في الاحتفاظ بمسار لا يعمل.

حسنًا ، يجب تدهور المسارات وإسقاطها بعد عدة عمليات إرسال فاشلة. ستتحلل أحدث البرامج الثابتة في كل مرة يتم الإبلاغ عن خطأ في تأكيد APS-DATA (مثل خطأ في التوجيه أو عدم تلقي APS-ACK).

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

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

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

لا تقوم deCONZ بأي اكتشاف للمسار يتم التعامل معه بواسطة مكدس Zigbee. يمكننا توسيع واجهة برمجة تطبيقات REST لإجراء عمليات إعادة المحاولة لبعض الأوامر (مثل أوامر التحكم) ولكن هذا أمر بسيط.

يمكن تكوين المكدس نفسه لإجراء محاولات متعددة لـ APS حتى الاستسلام. لكن هذا يمكن أن يفسد الكثير من الأشياء ويمنع قائمة الانتظار لفترة طويلة. أعتقد أنه من الأفضل اعتبار ذلك أكثر دقة في REST-API.

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

من الناحية النظرية ، فإن توجيه المصدر هو الكأس المقدسة لإصلاح كل شيء :)

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

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

يسعدني المساعدة في اختبار / استنشاق جسر Hue (الجيل الثاني والجيل 1) ، وبوابة innr ، ومركز IKEA ، وبوابة OSRAM Lightly Home ، لكنني بحاجة إلى بعض المدخلات حول إعداد الاختبار الذي يجب استخدامه (كم عدد أجهزة التوجيه ، والأجهزة الطرفية ، والمسافات بينها ، ...) وما الذي تبحث عنه.

Z-Stack FW هو أحد الأمثلة على FW الذي يقدم / يستخدم توجيه المصدر ويوصي به للشبكات الأكبر. لكنني رأيت أيضًا بعض التعليقات التي تشير إلى أنها لا تعمل بشكل جيد مع CC2351 الأضعف.

https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator

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

لا تقوم deCONZ بأي اكتشاف للمسار يتم التعامل معه بواسطة مكدس Zigbee. يمكننا توسيع واجهة برمجة تطبيقات REST لإجراء عمليات إعادة المحاولة لبعض الأوامر (مثل أوامر التحكم) ولكن هذا أمر بسيط.

يمكن تكوين المكدس نفسه لإجراء محاولات متعددة لـ APS حتى الاستسلام. لكن هذا يمكن أن يفسد الكثير من الأشياء ويمنع قائمة الانتظار لفترة طويلة. أعتقد أنه من الأفضل اعتبار ذلك أكثر دقة في REST-API.

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

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

من الناحية النظرية ، فإن توجيه المصدر هو الكأس المقدسة لإصلاح كل شيء :)

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

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

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

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

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

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

KISS - له معنى كبير بالنسبة لي.

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

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

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

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

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

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

يجب تنفيذ التعقيد في مكون deCONZ REST-API الإضافي أو مكون إضافي جديد لجهاز التوجيه ، نظرًا لأن البرنامج الثابت لا يحتوي على رؤية كافية حول هيكل الشبكة بالكامل ولا مساحة الفلاش. لهذا الغرض ، يمكن تمديد deCONZ::ApsDataRequest بخيار مسار المصدر في شكل std::vector<quint16> يحمل عناوين nwk لمسار.

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

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

ما لا نعرفه حتى الآن:

• هل تدعم جميع أجهزة التوجيه توجيه المصدر؟
• هل هناك أي بوابات تجارية تستخدم توجيه المصدر؟ نحتاج هنا إلى التعرف على حركة المرور وإلقاء نظرة على رؤوس NWK التي تحمل مسارات المصدر ولديها علامات محددة.
• بالنسبة للأجهزة التي تدعم توجيه المصدر ، ما مدى جودة عملها؟

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

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

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

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

يجب تنفيذ التعقيد في مكون deCONZ REST-API الإضافي أو مكون إضافي جديد لجهاز التوجيه ، نظرًا لأن البرنامج الثابت لا يحتوي على رؤية كافية حول هيكل الشبكة بالكامل ولا مساحة الفلاش. لهذا الغرض ، يمكن تمديد deCONZ::ApsDataRequest بخيار مسار المصدر في شكل std::vector<quint16> يحمل عناوين nwk لمسار.

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

• يُعرف المسار إلى المنسق بشكل أساسي لكل جهاز في الشبكة من خلال MTORRs
• يعرف المنسق كل مسار (كامل) لكل جهاز من خلال رسائل سجل المسار. لا حاجة إلى تحليل ، فقط نسخة من رسالة RR في جدول التوجيه المصدر

راجع فصل مواصفات زيجبي 3.6.3.5.4 والفصل 3.6.3.3

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

* Recursive query of network topology (Mgmt_Lqi_req). Thats, the easy one, this already works for mesh routing and could be adapted to source routes.

* Nodes are powered off. Here some logic needs to select alternate routes, which may also not work if their links are broken too.

* Nodes are powered on again.

* Nodes changing the nwk address.

* End-devices changing parents.

* End-devices joining, in multi-hop networks we don't know the parent without querying the network.

أعتقد أن هذه كلها تتم معالجتها بواسطة طبقة NWK داخل مكدس bitcloud. يجب أن يكون الأمر بسيطًا مثل تعديل بعض إشارات وقت التجميع (على غرار تمكين سلوك MTOR)

ما لا نعرفه حتى الآن:

* Do all routers support source routing?

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

* Are there any commercial gateways which use source routing? Here we need to sniff traffic and look at the NWK headers which hold the source routes and have respective flags set.

لا تعرف هذا ، ولا أعرف أيضًا ماذا سيخبرنا ذلك؟

* For the devices which support source routing, how well does it work?

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

كما قام Zigbee2MQTT بتمكينه لبعض البرامج الثابتة للمنسق ولم أجد بعد (بعد بحث google السريع) أي مشكلات مع أجهزة توجيه معينة لا تعمل بشكل جيد مع تمكين توجيه المصدر.

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

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

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

يُعرف المسار إلى المنسق بشكل أساسي لكل جهاز في الشبكة من خلال MTORRs
يعرف المنسق كل مسار (كامل) لكل جهاز من خلال رسائل سجل المسار. لا حاجة إلى تحليل ، فقط نسخة من رسالة RR في جدول التوجيه المصدر

راجع فصل مواصفات زيجبي 3.6.3.5.4 والفصل 3.6.3.3

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

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

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

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

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

deCONZ_ConBeeII_0x26600700_many2one.bin.zip

إليك البرنامج الثابت الذي تم تمكين توجيه الشبكة وتوجيه المصدر (حجم جدول سجل المسار 32). يمكنك تجربتها ولكن كما هو مذكور في توجيه مصدر الشبكة الأصغر الخاص بي لم يتم تشغيله في هذا التكوين.

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

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

أنا على raspbee I ، لذا لا يمكنني اختبار ذلك. هل يمكنك إنشاء واحد لذلك أيضًا؟

لست متأكدًا ، أحتاج إلى التحقق من تكوين المكدس الآخر الذي يستخدمه ConBee I و RaspBee I إذا كان ذلك ممكنًا.

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

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

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

لا ، لقد قمت للتو بتحديث البرنامج الثابت ، ولم يتم الإصلاح - تم إنشاء مسارات المصدر بعد وقت قصير من تلقي أوامر تسجيل المسار.

راجع للشغل لقد رأيت أن أجهزتي الطرفية من Xiaomi ترسل سجل المسار في الاستنشاق ...

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

يمكنني أن أجرب أيضًا للاختبار إذا كان بإمكاننا جعله يعمل مع Raspbee.

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

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

أنا على raspbee I ، لذا لا يمكنني اختبار ذلك. هل يمكنك إنشاء واحد لذلك أيضًا؟

لست متأكدًا ، أحتاج إلى التحقق من تكوين المكدس الآخر الذي يستخدمه ConBee I و RaspBee I إذا كان ذلك ممكنًا.

سيكون رائعا ...

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

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

متفق عليه

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

لا ، لقد قمت للتو بتحديث البرنامج الثابت ، ولم يتم الإصلاح - تم إنشاء مسارات المصدر بعد وقت قصير من تلقي أوامر تسجيل المسار.

أتساءل عما إذا كان ذلك مفيدًا لجهاز Philips ...

مرحبًا يا شباب ، لقد قمت بتشغيل البرنامج الثابت Z2M Source Routing لمدة 24 ساعة (يسمح فقط بـ 5 اتصالات مباشرة). لدي ~ 35 جهازًا. إنه يعمل بشكل جيد لكنني لاحظت أن أجهزة Hue تحتاج إلى دورة طاقة لإعادة الاتصال بعد أن انتقلت من FW الافتراضي إلى البرنامج الثابت SR. تمت إعادة توصيل Ikea و Xiaomi تلقائيًا. ربما يمكن أن يفسر هذا أجزاء من سلوك Hue الذي تراه؟

مرحبا،
أعدت اختبار لمبة TRADFRI E14 WS opal 400lm مع برنامج IKEA الثابت 2.3.050 وأحدث إصدار من deconz beta وأحدث البرامج الثابتة على Conbee I. يمكنني التأكد من تحسن اللمبات والاتصالات. يعمل استدعاء المشهد ، والتشغيل / الإيقاف ، والتلاشي للداخل والخارج بشكل أفضل الآن ولكن هناك مشكلة متبقية.

تم حل المشكلات الموثقة هنا # 2518 في الغالب. يبدو أن أوامر المجموعة (من phoscon gui) تعمل بشكل أفضل. # 2518 مغلق

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

العدد الجديد رقم 2892 الذي يظهر هو أنه إذا تم استدعاء مشهد داخل مجموعة ما وتشغيل جميع المصابيح المنتمية (بسبب المشهد) ولاحقًا مشهد آخر في تلك المجموعة مع تشغيل عدد قليل من المصابيح (محددة بالمشهد) تذكر ، المصابيح "غير المرغوب فيها" التي يجب أن تنطفئ البقاء على قيد الحياة.
علاوة على ذلك ، إذا قمت بإيقاف تشغيل المجموعة ، يتم إيقاف تشغيل مصابيح المشهد المحددة حاليًا فقط ويظل الآخرون من قبل (المشهد السابق من المجموعة) قيد التشغيل. يحتاجون إلى عدة أوامر إيقاف قبل الانطلاق.
تم وصف المشكلة هنا ولكنها موجودة في واجهة برمجة التطبيقات بالتأكيد لأنها لا تحدث أي فرق في حالة استخدام Phoscon أو واجهة برمجة التطبيقات نفسها. https://github.com/dresden-elektronik/phoscon-app-beta/issues/52

ملاحظة إضافية: استخدام أحدث إصدار من ikea fw 2.3.050 في 20.5.2020

نسخة الإصدار: 1.12.1
20 مايو 2020
الميزات والتغييرات الجديدة في الملحقات:
WS 1.0 (E14 ، E27 ، GU10) V-2.3.050.
ثابت في خارج الحالة بعد ترقية OTA.

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

manup ، أي أخبار عن إصدار البرامج الثابتة للمسار المصدر من conbee أنا؟ أنا أتطلع إلى اختبار ذلك :)

manup ، أي أخبار عن إصدار البرامج الثابتة للمسار المصدر من conbee أنا؟ أنا أتطلع إلى اختبار ذلك :)

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

manup ، أي أخبار عن إصدار البرامج الثابتة للمسار المصدر من conbee أنا؟ أنا أتطلع إلى اختبار ذلك :)

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

لا يبدو Hmmmm رائعًا ... manup ، أود المساعدة ، لكن لا يمكنني الوصول إلى هذا الرمز.

manup ، أي تقدم؟

manup ،

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

ما زال يحدث. manup أي تقدم و / أو تحديث بشأن هذه المشكلة؟

djwlindenaar @ JBS5 لقد طلبت من manup التحديث.

نعم ، لا تزال مشكلة - على الرغم من أنها أقل بكثير من ذي قبل.

ما هو آخر ما في القضية؟

لدي حوالي 20 طيفًا أبيض GU10 (الجيل الأول) متصل بجسر Hue وكجزء من ترشيد شبكة zigbee ، أردت ترحيل جميع أجهزتي إلى Deconz.

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

هل ديكونز أكثر استقرارًا أم أقل؟

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

@ salopette ليس لدي هذه التجربة. هل تمانع في فتح قضية منفصلة؟ أي سجلات؟

Mimiix تتعلق هذه المشكلة بالأضواء التي

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

@ JBS5 لأننا لا نعرف أي شيء عن إعداد هذا المستخدم. لا يوجد إصدار ولا سجلات ولا معلومات عن الإعداد. لسنا في وضع يسمح لنا بتحديد ما إذا كانت مشكلته متعلقة بهذا.

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

طلبت من manup ذات مرة النظر في هذا الأمر وتحديد أولوياته.

djwlindenaar كان

إعلان عام:

لقد تحدثت للتو مع manup على انفراد بشأن هذا. قال لي ما يلي:

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

تم إجراء بعض التغييرات بالفعل ولكنها ليست عامة بعد.
""

وسأطلعكم نشر جميع.

إعلان عام:

لقد تحدثت للتو مع manup على انفراد بشأن هذا. قال لي ما يلي:

My plan is that this next firmware is available within the next 2–3 weeks.

Some changes are already done but are not public yet.

وسأطلعكم نشر جميع.

بعد 3 أسابيع ، أي تحديث على هذا؟

@ JBS5 ليس 3 أسابيع بعد. انتظر الروبوت الذي لا معنى له هنا ؛)

بميد manup هذا الصباح مرة أخرى. حصلت على الرد التالي:

Have been crawling in the firmware the last couple of days to investigate the reboot issues and found some nasty bugs.
It will also contain a few routing changes, hope to get it out with the coming release.

The debug enhancements will follow after the next stable release.

لقد طلبت ETA وهو موجود عليه في هذه اللحظة.

@ JBS5 ليس 3 أسابيع بعد. انتظر الروبوت الذي لا معنى له هنا ؛)

بميد manup هذا الصباح مرة أخرى. حصلت على الرد التالي:

Have been crawling in the firmware the last couple of days to investigate the reboot issues and found some nasty bugs.
It will also contain a few routing changes, hope to get it out with the coming release.

The debug enhancements will follow after the next stable release.

لقد طلبت ETA وهو موجود عليه في هذه اللحظة.

حسنًا ، لقد قطعت وعدًا تجاه المجتمع ، لذا فمن الطبيعي أن يلتزموا بهذا الوعد ، 21 يومًا / 7 أيام = 3 أسابيع
من المؤسف أن تختبئ وراء Stalebot عندما تكون هذه المشكلة نشطة بالفعل منذ فبراير 2019. عندما تريد أن تكون المتحدث الرسمي باسم Dresden يتصرف على هذا manup يتعامل مع هذا :)

إذن ما هو ETA الآن مرت 2-3 أسابيع

@ lubbertkramer من فضلك كن معقولاً هنا ، Mimiix سابقًا هو مشاركة التحديثات بمجرد توفر بعضها ، لذلك من الصحيح تمامًا السؤال عن الوضع الحالي. الآن بالنسبة لـ ETA ، لم يتم الوعد بأي شيء وأنا أفهم أنه لن يتم ذلك ، لأن هذه أشياء معقدة. كما أعرف مانوب عندما أتحدث عن الأشياء السيئة ، فإنه للأسف لا شيء يمكن تسويته في غضون يوم واحد ، لا تظهر إلا بعد وقت طويل أو تتطور بعض الآثار الجانبية غير المتوقعة.

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

@ JBS5 ليس 3 أسابيع بعد. انتظر الروبوت الذي لا معنى له هنا ؛)

بميد manup هذا الصباح مرة أخرى. حصلت على الرد التالي:

Have been crawling in the firmware the last couple of days to investigate the reboot issues and found some nasty bugs.
It will also contain a few routing changes, hope to get it out with the coming release.

The debug enhancements will follow after the next stable release.

لقد طلبت ETA وهو موجود عليه في هذه اللحظة.

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

وهل هذه التغييرات في التوجيه تستند إلى نتائج djwlindenaar أم أن manup قادرة بالفعل على أن تكون أكثر تحديدًا؟

@ lubbertkramer من فضلك كن معقولاً هنا ، Mimiix سابقًا هو مشاركة التحديثات بمجرد توفر بعضها ، لذلك من الصحيح تمامًا السؤال عن الوضع الحالي. الآن بالنسبة لـ ETA ، لم يتم الوعد بأي شيء وأنا أفهم أنه لن يتم ذلك ، لأن هذه أشياء معقدة. كما أعرف مانوب عندما أتحدث عن الأشياء السيئة ، فإنه للأسف لا شيء يمكن تسويته في غضون يوم واحد ، لا تظهر إلا بعد وقت طويل أو تتطور بعض الآثار الجانبية غير المتوقعة.

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

أعتقد أنه من المعقول أكثر أن نجعل الناس يمرون بالاتصالات أو الوعود دون إلقاء "نكات" بعد مرور 2-3 أسابيع بمقدار 3 أسابيع دون متابعة. المستخدمون الذين حققوا كثيرًا وأجابوا هنا انتقلوا بالفعل بسبب عدم وجود متابعة / اتصال.

إذن ، بالعودة إلى المشكلة ، ما هي أحدث المعلومات حول هذه المشكلة؟

@ JBS5 ليس 3 أسابيع بعد. انتظر الروبوت الذي لا معنى له هنا ؛)

بميد manup هذا الصباح مرة أخرى. حصلت على الرد التالي:

Have been crawling in the firmware the last couple of days to investigate the reboot issues and found some nasty bugs.
It will also contain a few routing changes, hope to get it out with the coming release.

The debug enhancements will follow after the next stable release.

لقد طلبت ETA وهو موجود عليه في هذه اللحظة.

حسنًا ، لقد قطعت وعدًا تجاه المجتمع ، لذا فمن الطبيعي أن يلتزموا بهذا الوعد ، 21 يومًا / 7 أيام = 3 أسابيع
من المؤسف أن تختبئ وراء Stalebot عندما تكون هذه المشكلة نشطة بالفعل منذ فبراير 2019. عندما تريد أن تكون المتحدث الرسمي باسم Dresden يتصرف على هذا manup يتعامل مع هذا :)

إذن ما هو ETA الآن مرت 2-3 أسابيع

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

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

_كن التغيير الذي تريد أن تراه في هذا العالم_

@ JBS5 ليس 3 أسابيع بعد. انتظر الروبوت الذي لا معنى له هنا ؛)
بميد manup هذا الصباح مرة أخرى. حصلت على الرد التالي:

Have been crawling in the firmware the last couple of days to investigate the reboot issues and found some nasty bugs.
It will also contain a few routing changes, hope to get it out with the coming release.

The debug enhancements will follow after the next stable release.

لقد طلبت ETA وهو موجود عليه في هذه اللحظة.

حسنًا ، لقد قطعت وعدًا تجاه المجتمع ، لذا فمن الطبيعي أن يلتزموا بهذا الوعد ، 21 يومًا / 7 أيام = 3 أسابيع
من المؤسف أن تختبئ وراء Stalebot عندما تكون هذه المشكلة نشطة بالفعل منذ فبراير 2019. عندما تريد أن تكون المتحدث الرسمي باسم Dresden يتصرف على هذا manup يتعامل مع هذا :)
إذن ما هو ETA الآن مرت 2-3 أسابيع

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

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

_كن التغيير الذي تريد أن تراه في هذا العالم_

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

لقد مرت الأسابيع 2-3 التي قمت بنشرها كإعلان عام منذ أكثر من 3 أسابيع حتى الآن ، فما هي المتابعة؟

@ JBS5 ليس 3 أسابيع بعد. انتظر الروبوت الذي لا معنى له هنا ؛)
بميد manup هذا الصباح مرة أخرى. حصلت على الرد التالي:

Have been crawling in the firmware the last couple of days to investigate the reboot issues and found some nasty bugs.
It will also contain a few routing changes, hope to get it out with the coming release.

The debug enhancements will follow after the next stable release.

لقد طلبت ETA وهو موجود عليه في هذه اللحظة.

حسنًا ، لقد قطعت وعدًا تجاه المجتمع ، لذا فمن الطبيعي أن يلتزموا بهذا الوعد ، 21 يومًا / 7 أيام = 3 أسابيع
من المؤسف أن تختبئ وراء Stalebot عندما تكون هذه المشكلة نشطة بالفعل منذ فبراير 2019. عندما تريد أن تكون المتحدث الرسمي باسم Dresden يتصرف على هذا manup يتعامل مع هذا :)
إذن ما هو ETA الآن مرت 2-3 أسابيع

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

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

لقد مرت الأسابيع 2-3 التي قمت بنشرها كإعلان عام منذ أكثر من 3 أسابيع حتى الآن ، فما هي المتابعة؟

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

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

@ JBS5 ليس 3 أسابيع بعد. انتظر الروبوت الذي لا معنى له هنا ؛)
بميد manup هذا الصباح مرة أخرى. حصلت على الرد التالي:

Have been crawling in the firmware the last couple of days to investigate the reboot issues and found some nasty bugs.
It will also contain a few routing changes, hope to get it out with the coming release.

The debug enhancements will follow after the next stable release.

لقد طلبت ETA وهو موجود عليه في هذه اللحظة.

حسنًا ، لقد قطعت وعدًا تجاه المجتمع ، لذا فمن الطبيعي أن يلتزموا بهذا الوعد ، 21 يومًا / 7 أيام = 3 أسابيع
من المؤسف أن تختبئ وراء Stalebot عندما تكون هذه المشكلة نشطة بالفعل منذ فبراير 2019. عندما تريد أن تكون المتحدث الرسمي باسم Dresden يتصرف على هذا manup يتعامل مع هذا :)
إذن ما هو ETA الآن مرت 2-3 أسابيع

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

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

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

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

الحرج الوحيد في هذه القضية هو مانوب ومن الواضح أن درسدن غير قادر على حل هذه المشكلة. Conbee هو منتج تجاري ومع ذلك تأتي المسؤوليات. ولهذا السبب غادر الكثير منا بالفعل deCONZ / Conbee من أجل شريحة TI و Z2M ، والتي تعمل بلا عيب منذ ذلك الحين.

@ JBS5 ليس 3 أسابيع بعد. انتظر الروبوت الذي لا معنى له هنا ؛)
بميد manup هذا الصباح مرة أخرى. حصلت على الرد التالي:

Have been crawling in the firmware the last couple of days to investigate the reboot issues and found some nasty bugs.
It will also contain a few routing changes, hope to get it out with the coming release.

The debug enhancements will follow after the next stable release.

لقد طلبت ETA وهو موجود عليه في هذه اللحظة.

حسنًا ، لقد قطعت وعدًا تجاه المجتمع ، لذا فمن الطبيعي أن يلتزموا بهذا الوعد ، 21 يومًا / 7 أيام = 3 أسابيع
من المؤسف أن تختبئ وراء Stalebot عندما تكون هذه المشكلة نشطة بالفعل منذ فبراير 2019. عندما تريد أن تكون المتحدث الرسمي باسم Dresden يتصرف على هذا manup يتعامل مع هذا :)
إذن ما هو ETA الآن مرت 2-3 أسابيع

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

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

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

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

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

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

إعلان عام:

لقد تحدثت للتو مع manup على انفراد بشأن هذا. قال لي ما يلي:

My plan is that this next firmware is available within the next 2–3 weeks.

Some changes are already done but are not public yet.

وسأطلعكم نشر جميع.

لقد مرت الأسابيع 2-3 التي قمت بنشرها كإعلان عام منذ أكثر من 3 أسابيع حتى الآن ، فما هي المتابعة ، ماذا يمكن أن يتوقع المستخدمون؟

سيأتي الاعتماد الجديد في أقل من أسبوع. أقترح التزام الهدوء
وانتظر لمعرفة ما ستجلبه التغييرات الجديدة

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

لا تكن متأكدًا من أن المشكلات مرتبطة دائمًا بـ deCONZ ، وأحيانًا لا تكون كذلك.

في الأحد ، 6 سبتمبر ، 2020 ، 11:38 كتب lubbertkramer [email protected] :

@ JBS5 https://github.com/JBS5 ليس 3 أسابيع بعد. انتظرت الروبوت الذي لا معنى له
هنا ؛)
Pmedmanup https://github.com/manup هذا الصباح مرة أخرى. حصلت على
الرد التالي:

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

ستتبع تحسينات التصحيح بعد الإصدار الثابت التالي.

لقد طلبت ETA وهو موجود عليه في هذه اللحظة.

حسنًا ، لقد قطعت وعدًا تجاه المجتمع ، لذا فمن الطبيعي أن يحملكم
لهذا الوعد ، 21 يومًا / 7 أيام = 3 أسابيع
ثم من العرجاء الاختباء وراء stalebot عندما تكون هذه المشكلة بالفعل
نشط منذ فبراير 2019. عندما تريد أن تكون المتحدث الرسمي باسم مدينة دريسدن
تصرف على هذا النحو أو دع https://github.com/manup يتعامل مع هذا :)
إذن ما هو ETA الآن مرت 2-3 أسابيع

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

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

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

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

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

لذا ، مرة أخرى ، انشر تحديثًا أو توقف عن النشر خارج الموضوع :)

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment-687726432 ،
أو إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/AO4LI5G32N546L6GKHSHISLSENDABANCNFSM4GXPM2DA
.

@ morfei1 و Mimiix نأمل أن يأتي الإصدار القادم في غضون أسبوعين تقريبًا إذا كنت تبحث عن كيفية عمل الإصدار بواسطة DE ("15th" = قبل الدفع بقليل). ولا توجد كلمة إذا كان هناك إصلاح واحد موجود فيه مع أو بدون إجازات.
والبعض يقول (وأنا عدة مرات) كيف يعمل الدعم الرسمي ثم العملاء الذين يواجهون مشاكل كبيرة.
غير قابل للحفظ: ZHA في غضون أسبوع إلى أسبوعين سيبدأ الدعم الرسمي لـ Silabs EZSP جميع إصدارات بروتوكولات المكدس الخاصة بهم ، لذلك أعتقد أن أحد Sonoff Zigbee Bridge أو Elelabs-ELU013 / ELR023 هو الأفضل لوضع الأموال والحصول على المزيد من قوة RF و SoC ثم منتجات DE ودعم أفضل من المجتمع.
لكنني أنتظر الإصدار 2 من deCONZ REST-API قبل السماح لجميع منتجات DE RIP.

@ JBS5 ليس 3 أسابيع بعد. انتظر الروبوت الذي لا معنى له هنا ؛)
بميد manup هذا الصباح مرة أخرى. حصلت على الرد التالي:

Have been crawling in the firmware the last couple of days to investigate the reboot issues and found some nasty bugs.
It will also contain a few routing changes, hope to get it out with the coming release.

The debug enhancements will follow after the next stable release.

لقد طلبت ETA وهو موجود عليه في هذه اللحظة.

حسنًا ، لقد قطعت وعدًا تجاه المجتمع ، لذا فمن الطبيعي أن يلتزموا بهذا الوعد ، 21 يومًا / 7 أيام = 3 أسابيع
من المؤسف أن تختبئ وراء Stalebot عندما تكون هذه المشكلة نشطة بالفعل منذ فبراير 2019. عندما تريد أن تكون المتحدث الرسمي باسم Dresden يتصرف على هذا manup يتعامل مع هذا :)
إذن ما هو ETA الآن مرت 2-3 أسابيع

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

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

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

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

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

إعلان عام:
لقد تحدثت للتو مع manup على انفراد بشأن هذا. قال لي ما يلي:

My plan is that this next firmware is available within the next 2–3 weeks.

Some changes are already done but are not public yet.

وسأطلعكم نشر جميع.

لقد مرت الأسابيع 2-3 التي قمت بنشرها كإعلان عام منذ أكثر من 3 أسابيع حتى الآن ، فما هي المتابعة ، ماذا يمكن أن يتوقع المستخدمون؟

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

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

@ JBS5 ليس 3 أسابيع بعد. انتظر الروبوت الذي لا معنى له هنا ؛)
بميد manup هذا الصباح مرة أخرى. حصلت على الرد التالي:

Have been crawling in the firmware the last couple of days to investigate the reboot issues and found some nasty bugs.
It will also contain a few routing changes, hope to get it out with the coming release.

The debug enhancements will follow after the next stable release.

لقد طلبت ETA وهو موجود عليه في هذه اللحظة.

حسنًا ، لقد قطعت وعدًا تجاه المجتمع ، لذا فمن الطبيعي أن يلتزموا بهذا الوعد ، 21 يومًا / 7 أيام = 3 أسابيع
من المؤسف أن تختبئ وراء Stalebot عندما تكون هذه المشكلة نشطة بالفعل منذ فبراير 2019. عندما تريد أن تكون المتحدث الرسمي باسم Dresden يتصرف على هذا manup يتعامل مع هذا :)
إذن ما هو ETA الآن مرت 2-3 أسابيع

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

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

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

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

إعلان عام:
لقد تحدثت للتو مع manup على انفراد بشأن هذا. قال لي ما يلي:

My plan is that this next firmware is available within the next 2–3 weeks.

Some changes are already done but are not public yet.

وسأطلعكم نشر جميع.

لقد مرت الأسابيع 2-3 التي قمت بنشرها كإعلان عام منذ أكثر من 3 أسابيع حتى الآن ، فما هي المتابعة ، ماذا يمكن أن يتوقع المستخدمون؟

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

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

هذه إجابة صغيرة ، لذلك عندما أقرأ بشكل صحيح ، يمكننا أن نتوقع إجابة أكثر تفصيلاً في وقت لاحق من هذا الأسبوع لأنه قد مر ما يقرب من 4 أسابيع بدلاً من 2-3 أسابيع التي

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

@ lubbertkramer قلت لوك ، ليس قريبًا.

وبهذا ، سأغلق هذه المشكلة. سأفتح في غضون أيام قليلة أو عندما أجاب مانويل هنا.

مرحبًا مرة أخرى ، أعتقد أن الوقت قد حان لتحديث هذه المشكلة.

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

تحديث متقدم

(معاينة للإصدار التالي)

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

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

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

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

تكتشف deCONZ تلقائيًا ما إذا كان من الممكن الوصول إلى كل قفزة على الطريق وفي هذه الحالة فقط تستخدم مسار المصدر.
يتم تكوين مسارات المصدر خلف الكواليس بعناوين MAC الخاصة بالعقد لمقاومة تغييرات عنوان NWK.

إنشاء مسار مصدر ثابت

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

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

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

لإزالة مسار المصدر: حدد "إزالة مسار المصدر" في قائمة سياق عقدة الوجهة.

سيتم استخدام المسار للطلب التالي:

يعمل هذا بشكل جيد ويسمح بالكتابة اليدوية للتوجيه إذا لزم الأمر ، ويجب أن يكون مفيدًا للاختبار أيضًا.
لا يعمل هذا حاليًا إلا عند تكوينه عبر واجهة المستخدم الرسومية ، لكن يجب أن يكون متاحًا عبر REST-API لاحقًا.

هل هذا يصلح كل شيء؟

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

متى سيتم اصدارها؟

قريبًا ، في الإصدار 2.05.81 التالي ، لدي العناصر التالية (الخفيفة نوعًا ما) في قائمة المهام للإصدار:

• تخزين / استعادة مسارات المصدر في قاعدة البيانات.
• إصلاح التعامل مع عداد أمان NWK لإصلاح النسخ الاحتياطي بين مختلف ConBee / RaspBee وإعادة تشغيل لا شيء يعمل.
• دع GCFFlasher يتحقق من تشغيل البرامج الثابتة بعد التحديث.

لذلك مع manup رده ، تم تقديم إجابة. يرجى البقاء على الموضوع والموضوع.

مرحبًا مرة أخرى ، أعتقد أن الوقت قد حان لتحديث هذه المشكلة.

تحديث متقدم

(معاينة للإصدار التالي)

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

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

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

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

تكتشف deCONZ تلقائيًا ما إذا كان من الممكن الوصول إلى كل قفزة على الطريق وفي هذه الحالة فقط تستخدم مسار المصدر.
يتم تكوين مسارات المصدر خلف الكواليس بعناوين MAC الخاصة بالعقد لمقاومة تغييرات عنوان NWK.

إنشاء مسار مصدر ثابت

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

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

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

لإزالة مسار المصدر: حدد "إزالة مسار المصدر" في قائمة سياق عقدة الوجهة.

سيتم استخدام المسار للطلب التالي:

يعمل هذا بشكل جيد ويسمح بالكتابة اليدوية للتوجيه إذا لزم الأمر ، ويجب أن يكون مفيدًا للاختبار أيضًا.
لا يعمل هذا حاليًا إلا عند تكوينه عبر واجهة المستخدم الرسومية ، لكن يجب أن يكون متاحًا عبر REST-API لاحقًا.

هل هذا يصلح كل شيء؟

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

متى سيتم اصدارها؟

قريبًا ، في الإصدار 2.05.81 التالي ، لدي العناصر التالية (الخفيفة نوعًا ما) في قائمة المهام للإصدار:

• تخزين / استعادة مسارات المصدر في قاعدة البيانات.
• إصلاح التعامل مع عداد أمان NWK لإصلاح النسخ الاحتياطي بين مختلف ConBee / RaspBee وإعادة تشغيل لا شيء يعمل.
• دع GCFFlasher يتحقق من تشغيل البرامج الثابتة بعد التحديث.

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

عدة أسئلة للمتابعة لدي:

• متى ستتوفر أعلاه كتحديث في الإصدار التجريبي / الثابت؟

• هل سيكون هناك اختلاف في كيفية العمل أعلاه فيما يتعلق بـ conbee 1/2 و Raspbee أم سيكون كل هذا متشابهًا؟

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

مرحبًا lubbertkramer

يمكنني الإجابة على رقم 1: الإصدار 2.05.81 متوقع في الخامس عشر من الشهر (بناء Windows بعد بضعة أيام). لقد وضعت ذلك في إعلان سابقًا في Discord ، لكنني اكتشفت أن هذا ليس هو الحال بالنسبة لـ Github. سأضيف ذلك إلى الملف التمهيدي! خطأي!

تحرير: هل طلب سحب لملف readme.md. لست متأكدًا من كيفية تشغيل القناة الثابتة التي تحتاج إلى توضيح قليلاً.

هل سيكون هناك اختلاف في كيفية العمل أعلاه فيما يتعلق بـ conbee 1/2 و Raspbee أم سيكون كل هذا متشابهًا؟

يجب أن تعمل بنفس الطريقة ، لقد قمت الآن بنقل الكود إلى RaspBee I / ConBee I ويتم استخدام مسارات المصدر هناك بنفس الطريقة.

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

يرسل المكرر إطارات حالة ارتباط NWK الخاصة به ، لكن التقارير وقائمة الجوار الفارغة:

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

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

هناك مشكلة مع مكرر USB Tradfri أو قابس Tradfri؟

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

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

شكر!

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

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

صفحة الويب التي تحتوي على سجل تغيير tradfri معطلة ، للتحقق مما تم إصلاحه في أحدث إصدار.

أحدث ملفات البرامج الثابتة متوفرة الآن على الإنترنت:

ConBee الثاني

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26650700.bin.GCF

RaspBee II

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_RaspBeeII_0x26650700.bin.GCF

RaspBee I و ConBee I

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_Rpi_0x26370500.bin.GCF

• تم تمكين هذه التوجيهات المصدر مع الحد الأقصى. 32 مسارًا مصدرًا ، حيث يتم استبدال الإدخالات الأقدم تلقائيًا بأحدثها. من المرجح أن يتم زيادة المبلغ في الإصدارات اللاحقة ، ولكن من المفترض أن يعمل بشكل جيد بالفعل.
• في حالة وجود مسار مصدر ومدخل مسار "عادي" ، يُفضل توجيه المصدر. هذا غير قياسي ولكن يبدو أنه يعمل بشكل أفضل.
• يحتوي البرنامج الثابت على تحسينات عامة لمتانة البروتوكول التسلسلي.
• حصل كل من ConBee II و RaspBee II على معالجة محسّنة لعداد الإطارات ، للتخفيف من المشاكل حيث قد يبدو أن الشبكة قد فقدت بعد دورة الطاقة حتى يصل عداد الإطارات إلى قيمته القديمة مرة أخرى.

manup هل البرامج الثابتة لـ ConBee أسقطت معرف الأمر version 0x0D ؟ لم أعد أتلقى أي رد على هذا الأمر بعد الآن

Adminiugamanup الأمور حول البرامج الثابتة: الرجاء استخدام # 3260.

أحدث ملفات البرامج الثابتة متوفرة الآن على الإنترنت:

ConBee الثاني

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26650700.bin.GCF

RaspBee II

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_RaspBeeII_0x26650700.bin.GCF

RaspBee I و ConBee I

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_Rpi_0x26370500.bin.GCF

• تم تمكين هذه التوجيهات المصدر مع الحد الأقصى. 32 مسارًا مصدرًا ، حيث يتم استبدال الإدخالات الأقدم تلقائيًا بأحدثها. من المرجح أن يتم زيادة المبلغ في الإصدارات اللاحقة ، ولكن من المفترض أن يعمل بشكل جيد بالفعل.
• في حالة وجود مسار مصدر ومدخل مسار "عادي" ، يُفضل توجيه المصدر. هذا غير قياسي ولكن يبدو أنه يعمل بشكل أفضل.
• يحتوي البرنامج الثابت على تحسينات عامة لمتانة البروتوكول التسلسلي.
• حصل كل من ConBee II و RaspBee II على معالجة محسّنة لعداد الإطارات ، للتخفيف من المشاكل حيث قد يبدو أن الشبكة قد فقدت بعد دورة الطاقة حتى يصل عداد الإطارات إلى قيمته القديمة مرة أخرى.

كيف أقوم بعمل فلاش لهذه البرامج الثابتة (أستخدم صورة deCONZ Docker من marthoc)؟

لقد قمت بتنزيل الملف (ConBee II) ولكن تعليمات التحديث اليدوي لا تنطبق على صورة marthoc's deCONZ Docker ولا يسمح دليل marthoc's deCONZ باستخدام برنامج ثابت غير مدرج في الصورة (وهذا الملف غير مدرج كما تتوفر).

كيف أقوم بعمل فلاش لهذه البرامج الثابتة (أستخدم صورة deCONZ Docker من marthoc)؟

أقوم فقط بتوصيل USB dongle بجهاز كمبيوتر محمول يعمل بنظام Windows والقيام بذلك من هناك والعودة إلى Synology NAS الخاص بي عند الانتهاء.

كيف أقوم بعمل فلاش لهذه البرامج الثابتة (أستخدم صورة deCONZ Docker من marthoc)؟

أقوم فقط بتوصيل USB dongle بجهاز كمبيوتر محمول يعمل بنظام Windows والقيام بذلك من هناك والعودة إلى Synology NAS الخاص بي عند الانتهاء.

هل توجد أداة مساعدة لنظام التشغيل Windows لفلاش البرامج الثابتة؟ إذا كان الأمر كذلك ، هل يمكنك مشاركة الرابط؟

كيف أقوم بعمل فلاش لهذه البرامج الثابتة (أستخدم صورة deCONZ Docker من marthoc)؟

أقوم فقط بتوصيل USB dongle بجهاز كمبيوتر محمول يعمل بنظام Windows والقيام بذلك من هناك والعودة إلى Synology NAS الخاص بي عند الانتهاء.

هل توجد أداة مساعدة لنظام التشغيل Windows لفلاش البرامج الثابتة؟ إذا كان الأمر كذلك ، هل يمكنك مشاركة الرابط؟

https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Update-deCONZ-manually#update -in-windows

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

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

هل هذا يصلح كل شيء؟

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

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

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

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

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

لدي 21 مصباحًا (4-980lu WS ، 17-1000lu WS) ، 3 مقابس و 3 (5 أزرار) أجهزة تحكم عن بعد مستديرة من Ikea. كلهم على أحدث طرازات Ikea FWs. لم أشعر أبدًا بعدم الاستقرار معهم منذ حوالي +1.5 عام. Nighter مع أي من إصدارات deCONZ السابقة أو إصدارات FW ولا مع الإصدار الحالي. أنا أقوم بتشغيل مستقر .81 مع أحدث RaspBee FW 0x26370500 ، ولا أواجه أي مشاكل خلال الأسبوع الأخير من استخدامها.

أعتقد ... (ربما لست على حق تمامًا) ليس لدى Ikea مشكلة عامة ، لكن الإعداد محدد. هناك العديد من العوامل المختلفة التي يمكن أن تؤثر على سلوكهم وأدائهم في deCONZ وبشكل عام.

أعتقد أن معظم المشكلات حدثت مع مصابيح Ikea GU10. لقد تحسن الاستقرار بشكل كبير بمرور الوقت ، ولكن كانت الفوضى في أواخر عام 2018 عندما بدأت. اضطررت إلى إعادة تدوير واحدة من 30 GU10 كل أسبوعين في المتوسط ​​للإصدار / البرامج الثابتة للأشهر الثلاثة الماضية.

أعتقد أن معظم المشكلات حدثت مع مصابيح Ikea GU10. لقد تحسن الاستقرار بشكل كبير بمرور الوقت ، ولكن كانت الفوضى في أواخر عام 2018 عندما بدأت. اضطررت إلى إعادة تدوير واحدة من 30 GU10 كل أسبوعين في المتوسط ​​للإصدار / البرامج الثابتة للأشهر الثلاثة الماضية.

ممكن ان يكون. لم يتلق GU10 تحديث FW مثل أضواء Ikea الأخرى ، على حد علمي. في الآونة الأخيرة ، تجاهلناه في قنوات الخلاف. يواجه المستخدم الذي يقوم بتشغيل أضواء GU10 Ikea مثل هذا السلوك. لم يكن هناك ما حاولناه ، لا شيء يبدو أنه حل مشاكله. حتى أنه شارك معنا اشترى Ikea Tradfri Hub ولديه أيضًا نفس التجربة السيئة ، حتى مع Ikea Hub و GU10 light / s.

لذا ، أعتقد أنها مسألة وقت تقوم Ikea بإصدار FW جديد لهذا النوع من الأضواء ربما لحل / إصلاح هذه المشكلة ...

أتساءل عما إذا كان djwlindenaar قد قام بالفعل بالتحديث إلى أحدث برامج deCONZ والبرامج الثابتة وقادر على مشاركة تجاربه؟ :)

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

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

لقد قمت بالتحديث إلى أحدث البرامج الثابتة منذ يومين ، ومنذ ذلك الحين ، تم تبديل مفاتيح حائط Xiaomi (ctrl_neutral2 ، 11-25-2017) من تلقاء نفسها 3 مرات. لم أواجه مثل هذه المشكلة من قبل.

وهو متصل بالمنسق عبر لمبة Tradfri E27 CWS على 1.3.009.

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

لدي لمبات Tradfri:

• E27 CWS على 1.3.009
• E14 W في 1.2.214
• باهتة لاسلكي على 1.2.248
• 17 * GU10 WS في 1.2.221

يمكنني رؤية ملفات Trafri OTA التي تم تنزيلها ولكن لا شيء يحدث. ماذا علي أن أفعل؟

كمرجع ، هذه هي الطريقة التي تبدأ بها الحاوية:

docker run -d --name=deconz --net=host --restart=always -v /etc/localtime:/etc/localtime:ro -v /opt/otau:/root/otau -v /opt/deconz:/root/.local/share/dresden-elektronik/deCONZ --device=/dev/ttyACM0 -e DECONZ_WEB_PORT=801 -e DECONZ_WS_PORT=445 -e DECONZ_VNC_PORT=5930 -e DECONZ_VNC_PASSWORD=... -e DECONZ_VNC_MODE=1 -e DEBUG_INFO=1 marthoc/deconz

@ ReX1983 هذا ليس له علاقة بهذه المشكلة هنا afaik. الرجاء فتح قضية منفصلة. أعتقد أنه يجب عليك النشر في Docker version repo. https://github.com/marthoc/docker-deconz

ملاحظة بشأن الاعتدال:

قبل أن يختلط كل شيء هنا ، أود تحديد نطاق هنا.

أي شيء يتعلق بالمشكلة الأصلية: أضواء ايكيا التي تفقد الاتصال أحيانًا مسموح بها في هذه المشكلة.

يمكن نشر أي مشكلة أخرى متعلقة بالبرنامج الثابت هنا

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

@ JBS5 ،

لقد قمت للتو بتثبيت البرامج الثابتة وأحدث برنامج deCONZ .deb. حتى الآن يمكنني أن أؤكد أن توجيه المصدر يعمل ، بالطبع لا توجد استنتاجات بشأن الاستقرار بعد. سأبقيك على اطلاع

ZigBee Network Layer Data, Dst: 0x0ea4, Src: DeConz
    Frame Control Field: 0x0608, Frame Type: Data, Discover Route: Suppress, Security, Source Route Data
    Destination: 0x0ea4[0x0ea4]
    Source: 0x0000[DeConz]
    Radius: 10
    Sequence Number: 190
    [Extended Source: dresden-_ff:ff:00:c4:9a (00:21:2e:ff:ff:00:c4:9a)]
    [Origin: 366]
    Source Route, Length: 2
        Relay Count: 2
        Relay Index: 1
        Relay 1: 0xc803[0xc803]
        Relay 2: 0xf1e5[0xf1e5]
    ZigBee Security Header

@ ReX1983 انظر كيف يعمل البرنامج المساعد OTA https://github.com/dresden-elektronik/deconz-ota-plugin وتحديث أجهزتك.
آسف ولكن مشكلة اتصالات جهاز ايكيا واحدة.

تضمين التغريدة
أستطيع أن أؤكد أنه ليس فقط بسبب المصابيح الكهربائية GU10. واجهت مشكلات في التوجيه وفقدت الاتصال لفترة طويلة مع عدم وجود GU10 في نظامي.

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

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

tubalainen هل أنت مشترك في إضافة HA؟

tubalainen هل أنت مشترك في إضافة HA؟

لا ، أنا أستخدم HA Core على دبيان في عامل الإرساء - لذلك أستخدم أيضًا https://github.com/marthoc/docker-deconz stand-a-lone docker package. كلاهما يستخدم ملف .deb المقدم من dresten لذا يجب أن يعملوا بشكل متطابق. لست متأكدًا مما إذا كان المكون الإضافي OTAU مضمنًا في الوظيفة الإضافية deconz HA ....

مجرد تقطيع مع ملاحظاتي حتى الآن ؛

لدي فقط مشاكل مع Ikea GU-10 الخاص بي (23 منها) ، وأنا أستخدم مساعد المنزل ، الذي يتصل بـ deconz (عامل الإرساء) عبر بقية api ، ويمكنني رؤية HA يطلق الأحداث للتخلص من النجاح.

عندما أستخدم HA للتشغيل ، فإن 17 مصباحًا ، واحدة تلو الأخرى (مباشرة بعد بعضها البعض) ربما يتم تشغيل 3 من 17 دوسنت ، لكن HA تراها تعمل.
لكن ، إذا صنعت مجموعة في deconz. ضع كل الأضواء في تلك المجموعة ، وأخبر HA بتشغيل تلك المجموعة ، لم تكن هناك أية مشكلات حتى الآن ، كل الأضواء مضاءة.

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

هل هو قيد على بقية api ربما؟

MartinTerp ، إذا كنت تستخدم

الحل الخاص بي لهذا هو تأخير 5 ثوان بين الأوامر. فمثلا
إذا كنت أرغب في تبديل أضواء غرفة نومي في الساعة 23:00 في bri: 127 و ct: 454 ، وفي الردهة أيضًا ، أعطي 5 ثوانٍ تأخير لإحدى الغرف. إذا لم أضع التأخير ، فسوف يفشل بشكل عشوائي في إكمال الأمر الكامل لإحدى الغرف أو ربما لكليهما. أنا جربت كثيرا مع هذا. إنه شيء مشابه مثل حشرة Ikea ، لا يمكنه التعامل مع تبديل اللون والسطوع في نفس الوقت.

لا أعرف بالضبط ما هذا ، خطأ deconz ، قيود zigbee بشكل عام أو خطأ Ikea FW. ربما يكون عدم معرفتي بكيفية عمل zigbee ، لكن التأخير 5 ثوانٍ يعمل دائمًا بالنسبة لي.

كقاعدة عامة ، أستخدم دائمًا: رمل أقل قدر ممكن من الأوامر في وقت واحد أو استخدم تأخيرًا. وهكذا تحافظ على نظافة القناة.

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

@ morfei1 أنا أستخدم حلاً مشابهًا ويعمل معظم الوقت مع تأخير 5 ثوانٍ بين جميع الأوامر.
MartinTerp لقد واجهت أيضًا هذه المشكلة مع أجهزة أخرى غير مصابيح IKEA-Tradfri ، على سبيل المثال OSRAM Smart Plugs and Light Strips. أعتقد أنه من الممكن على الرغم من أن المشكلة كانت بسبب بعض عربات التي تجرها الدواب Tradfri-Lights التي لم تعيد توجيه الأوامر.

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

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

اعتدت أيضًا على استخدام التأخيرات + التي أرسلها وإيقافها من المساعد المنزلي مرتين لكل أتمتة مشغلة.

لقد قمت الآن بإزالة التأخيرات وكرر الأوامر منذ .82.

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

MustafaHosny اللهم امين يارب

هل يمكننا إجراء مناقشة حول كيفية تحديث البرامج الثابتة للجهاز؟

نحن لا نتحدث عن تحديث البرامج الثابتة؟

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

أقترح فتح مشكلة منفصلة لذلك مثل "ليست كل الأضواء تتفاعل عند إرسال أوامر أحادية الإرسال إلى أضواء متعددة".

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

محجوب من قبل Mimiix

محجوب من قبل Mimiix

inconsx @ ReX1983 اعتقدت أنني كنت واضحًا على https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment -696541484 و https://github.com/dresden-elektronik/deconz- rest-plugin / issues / 1261 # issuecomment -696046160

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

إذن ها هي ملاحظاتي ، لقد قمت بالترقية إلى أحدث البرامج الثابتة و deconz api. أدير شبكتي من HA.

لدي حوالي 72 عقدة ، معظمها من مصابيح IKEA GU10. بعد الترقية ، لاحظت جهازي GU10 مختلفين "ماتا" يومين مختلفين ، والطريقة الوحيدة لاستعادته هي دورة الطاقة. يستخدم GU10 تركيبات 1.2.217 و 1.2.221. سأحاول ترقيتهم جميعًا إلى نفس الإصدار.

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

لقد حصلت للتو على واحدة من لمبة IKEA TRADFRI الخاصة بي E14 W op / ch 400lm الإصدار 1.2.214 توقفت عن الاستجابة. لقد قام هذا المصباح بهذا عدة مرات وفي مختلف البرامج الثابتة deconz. الآن أستخدم deconz 26370500 و 2.05.82.

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

هل رأيت تحسنًا في الاستقرار مع مصابيح GU10 هذه بعد التحديث إلى 2.3.050؟ أنا الآن على 0x26650700 ومنذ التحديث إلى 2.3.050 (من 17 لمبة) يبدو أن شبكتي أكثر استقرارًا. لا تتوقف الأجهزة عن العمل خلال الليل وتعمل أزرار / مفاتيح أكارا الخاصة بي في المحاولات الأولى. إنه الآن 4 أيام ، لذا من المبكر القول.

لدي فقط 4 GU10 ، أعتقد أنها من الإصدار الأول الذي تم إصداره

يوجد بالفعل إصدار أرخص من IKEA GU10 (W فقط). لم يتم تحديثها مطلقًا إلى برنامج 2.x ولا تزال تعمل على 1.2.214. وكانت هذه هي الأكثر إشكالية. أنا شخصياً أستسلم فقط والآن هم يسيرون بسلاسة مع مركز ايكيا.

أعتقد أن antonbo يقترب من مسار المشكلة.
تستخدم ايكيا صور البرامج الثابتة نفسها مع أجهزة مختلفة (محركات PSU / LED) ولديها إعدادات مختلفة في "بيانات المستخدم" للأجهزة المختلفة (ويتم تخزين معرف الطراز بها). لذلك يمكن أن تعمل إحدى البرامج الثابتة بشكل جيد على جهاز واحد (E14) وتواجه مشكلات في الأجهزة الأخرى (GU10 / E27).
يتمثل أحد الاختلافات في أن IKEA GW يعمل في وضع ZLL (على Zigbee PRO) ولا يسحب حالة الجهاز فقط استمع إلى تغييرات الحالة التي ترسلها الأجهزة في الشبكة (وفقًا لمعيار Zigbee PRO / ZB3) ومزجها مع HUE وغيرها يمكن للبائعين الذين يسحب المنسق الحالة من الأجهزة (ليس سلوك ZB3) إحداث فوضى واحدة في الشبكة.
لدي أقدم IKEA RGBW وواحد E27 Opal WW على البرامج الثابتة القديمة المحدثة (1.X) التي تعمل بشكل جيد ومجموعة ZB3 GU10 WS الجديدة التي تعمل بشكل رائع. يتكون العمود الفقري الخاص بي من حوالي 10 مقابس IKEA تثبت استقرار اتصال الشبكة وأيضًا تعمل مستشعرات Xioami الخاصة بي بشكل جيد مع جميع هذه المقابس.
شعوري هو أن هذه ليست مشكلة عامة أكثر من HW وربما FW بالاشتراك مع تخطيط الشبكة وتجنب بعض الأجهزة ذات المشكلات (مثل OSRAM Outdoor Plug الذي يفسد الحزم ويفقد الأطفال طوال الوقت).

manup لا يسعني إلا أن أقول إن البرنامج الثابت الجديد جعله أسوأ بكثير من ذي قبل بالنسبة

أتساءل عما إذا كان أي شخص يعرف ما إذا كان إصدار GU10 الأحدث لا يزال يواجه مشكلات أم أنه لا يواجه المشكلات؟ سمعت أن الأجهزة الأحدث تعمل بنظام zigbee 3.0 ، وزوجتي ليست سعيدة بهذه المشكلات ، لذا يمكنني تغييرها جميعًا إذا كان ذلك مفيدًا؟

كان لدي ضوء معلق هذا الصباح. أعتقد أنها واحدة من الأحدث.

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

@ JBS5djwlindenaarlubbertkramer أي ملاحظات على أحدث برنامج مبني بالمقارنة مع هذه القضية؟

يمكنني أن أضيف أنه لمدة 48 ساعة لم أواجه أي مشكلات حول ما يتناوله هذا الموضوع وما واجهته سابقًا.

ومع ذلك ، تحتاج إلى إضافة ما يلي

• أعد تشغيل الحاوية مع deconz كل ليلة
• نقل التجميع من Home-Assistant إلى deconz / phoscon للتعامل معه.

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

Mimiix ، حسنًا ، من المبكر معرفة ذلك.

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

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

توقفت لمباتي E27 Ikea بشكل جماعي للتعاون.
حتى الآن ، نجح ركوب الدراجات في الطاقة لعدد قليل منهم. 3 لم يعودوا بعد. أعتقد أنني يجب أن أعيد إضافتهم ... :(

البرامج الثابتة: 26610700
الإصدار: 2.05.84 / 14.9.2020
(Raspbee2)

umrath يبدو أن هذا ليس له علاقة بالمشكلة التي تم تناولها في هذه المشكلة. الرجاء فتح مشكلة منفصلة :)

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

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

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

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

يُظهر إطلاق المتشمم نفس المشكلة:

• لا تزال الأجهزة ترسل أوامر NWK Link Status بشكل دوري ؛
• ولكن مع وجود قائمة فارغة دائمًا ، يبدو أنهم يتجاهلون جميع أجهزة التوجيه المحيطة ؛
• أنها ACK الأوامر الواردة على مستوى MAC ؛
• إنهم يتفاعلون مع طلبات منارة ويرسلون إشارة تنبيه ، ولكن هذا هو "الرد" الوحيد الذي يقدمونه.

بطريقة ما يبدو أن مكدس Zigbee على أجهزة IKEA يتعطل جزئيًا لطبقات NWK و APS وما فوق أو ربما تكون المخازن المؤقتة NWK الواردة ممتلئة ولم يتم إصدارها أبدًا.

حاولت إعادة تشغيل الأجهزة عن طريق إرسال:

• مغادرة ZDP مع إعادة الانضمام ؛
• NWK غادر مع إعادة الانضمام (المستوى الأدنى).

كلاهما تم قبوله عند مستوى MAC ولكن يتم تجاهلهما بخلاف ذلك.

لقد حاولت بعد ذلك تزييف أوامر حالة المنسق NWK Link بإدخال صالح يشير إلى أن الجهاز يعمل بتكلفة ارتباط وارد وصادر (3/3) على أمل أن يلتقط الجهاز المنسق في جدول الجوار. ... لم يعمل أيضا.

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

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

manup هل أنت قديم E27 واحد LL مع مجموعة تشخيصية؟
ربما يكون من المثير للاهتمام البحث عما إذا كان هناك شيء ما يحدث مع العدادات هناك بين بضعة أسابيع.
لا يمكن إصلاح المشكلة ولكن إعطاء تلميح واحد من wot الثابتة لا تطرف.
حسن الملاحظة والاستنتاجات ماندي !!

أعتقد أن Silabs تحصل على المزيد من البحث عن الأخطاء لأحد أكبر العملاء ؛-)

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

mvjt هل تستخدم Rasp / CornBee مع Z2M ​​أو منسق آخر؟
تعمل مجموعات زيجبي المختلفة بطرق مختلفة ويمكن أن تواجه / تصنع مشاكل مختلفة.

تحرير: آسف أرى ZZH = منسق TI جديد.
deCONZ NCP = Atmel / Microchip
أجهزة ايكيا / NCP = Sirlabs EFR32 / EZSP

أستطيع أن أؤكد أن HA / ZHA / Zigpy / Bellows يعمل بشكل رائع مع وحدة "Billy EZSP" = IKEA ICC-1-A كمنسق مع أجهزة التوجيه وأجهزة النهاية من IKEA من IKEA و Xiaomi وبدون أجهزة توجيه OSRAM أو Xiaomi.

MattWestb نعم ، يحتوي E27 على مجموعة التشخيص ، لكنني لم

على الأقل في الماضي ، حدثت المشكلة التي أراها أيضًا مع TI CC253X وفي نهاية المشكلة تم ذكر CC26X2R1 ، ولكن كانت هذه هي الحالة في يناير ، ربما تحسنت في غضون ذلك. https://github.com/Koenkk/zigbee2mqtt/issues/2032#issuecomment -547483373

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

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

manup لدي سيناريو واحد يجتاز "مشكلة ايكيا" بشكل جيد للغاية.
إذا كنت قد قمت بإعداد شبكتك ، فستبدأ بمفتاح شبكة واحد ويبدأ عداد إطار الأمان في وضع علامة. إذا لم يكن لديك إصلاح الشبكة أو لف مفتاح الشبكة لفترة طويلة جدًا ، فإن العداد سيتوقف لأنه وصل إلى الحد الأقصى 0xFFFFFFFF (32 بت) ولا يمكن زيادته.
ثم يقوم الجهاز بإلقاء جميع البيانات الواردة في طبقة الزيجبي لأن عداد الإطارات خاطئ ولكن طبقة الشبكة السفلية لا تزال تعمل بشكل طبيعي.
المشكلة لا أعرف طريقة واحدة للحصول على مكانة عداد إطار الأمان للأجهزة. أعتقد أن هذا غير ممكن رؤيته في Wireshark (التفكير = عدم المعرفة).

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

يوصى بتدوير مفتاح الشبكة على أساس منتظم في شبكة ZB3 لإبقائها آمنة ثم إعادة ضبط عداد إطار الأمان حتى لا يتم إيقافه.
بعض المعلومات AN1233: Zigbee Security 2.1.6 عداد إطار أمان الشبكة.

إنها عملية عصف ذهني واحدة ولكن يمكن أن تكون المشكلة تأتي بعد وقت طويل من تشغيل الشبكة.

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

Hrm ، من المؤكد أن تشغيل مفتاح الشبكة سيؤدي إلى إسقاط جميع xiaomis.

خطأ بنسبة 200٪ مؤمن أنهم لا يقومون بالتحديث ويتركون الشبكة (القديمة لا ZB3) !!!

Adminiuga هل تحاول تمرير مفتاح الشبكة على EZSP؟
أجد أنها مثيرة للاهتمام من النتيجة !!!

لم أحاول لف مفتاح الشبكة. في الواقع سيكون من المثير للاهتمام معرفة عدد التنفيذ الذي يلف المفتاح على أساس منتظم.
لكن يمكنني أن أؤكد أن تغيير عموم المعرف لديه فرص عالية جدًا في سقوط xiaomis ، مثل 4 من 5 فرص

لقد رأيت بعض اختبارات الاختراق الأمني ​​التي تقوم باستنشاق الهوية الشاملة من الشارع والعودة عدة مرات مع بضعة أشهر بين عدم قيام مورد الإضاءة الكبير (غير المذكور هنا) بإدخال مفتاح الشبكة بعد عام واحد (Mariahilferstraße في Wien ) لذلك من المرجح أن يكون لديك الحق (agen).

إذا وفقط إذا كان عداد إطار الأمان هو الذي يقوم بالمشكلة ، فعندئذٍ يفعل الشيء نفسه بالنسبة لجميع أجهزة zigbee 3 الحقيقية ، فسيتم تحديده في "مواصفات سلوك الجهاز الأساسي" ويوصى به في LL القديم ولكن من المحتمل جدًا ألا يكون بدون أجهزة zigbee PRO (HA و LL القديمة) أو أجهزة غير معتمدة (بدون اسم .... ميل).
ثم هو أفضل "يدوي" لف مفاتيح الشبكة أو مرتين في السنة ولا تحتاج إلى هدم المنزل لإعادة البناء في الأجهزة مرات أكثر في الفم ، ثم يتوقفون ويأخذون إعادة ضبط / إعادة الانضمام إلى مستشعرات Xiaomi القديمة التي لا يتم عادة مدمج في هيكل المنزل ويسهل إعادة ضبطه (عادةً ما يكون مفتوحًا للانضمام والضغط على الزر ويتم توصيلهما).
تقوم Menny "Chinese Zigbee 3" بإلقاء عداد إطار الأمان "القديم" بعد إعادة تعيين الطاقة واستخدام واحد جديد من الحزمة الأولى القادمة من جيرانها (لاحظ أنه بعد ذلك تم اختبار مشكلات tasmotas zigbee 3 ، ثم تمت إعادة ضبط عداد NCPs بشكل خاطئ عند إعادة التشغيل) لذلك هم فقط يعيدون الطاقة ويعودون.

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

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

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

djwlindenaar أتساءل عما إذا كان لديك أي نتائج جديدة لأنك قادر على تحليل انقطاع المصباح مرة أخرى ، كما يمكنني القيام به. هي موضع تقدير كبير النتائج الخاصة بك والرؤى. :)

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

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

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

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

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

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

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

فقط السطوع وجميع سمات الألوان المحددة مثل colorX و colorY ودرجة حرارة اللون.
بالنسبة للبرامج الثابتة ، أوصي دائمًا بأحدث إصدار 0x26660700 (في حالة ConBee II و RaspBee II).

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

manup ، أعتقد أن هذا التحديث حل أيضًا مشكلات الاستقرار مع أجهزة أكارا. شكر

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

manup ، أعتقد أن هذا التحديث حل أيضًا مشكلات الاستقرار مع أجهزة أكارا. شكر

لسوء الحظ ، لا تزال المشكلة (# 3605) هنا ، لقد أسرعت إلى الاستنتاجات مبكرًا جدًا