نجح ضم الجهاز إلى Bluetooth Mesh، فلماذا لا يستجيب المصباح؟

يظهر الجهاز في نتائج المسح. تضغط «إضافة»، ويعلن السجل نجاح Provisioning، وتظهر خانة جديدة في البوابة. يبدو أن العمل انتهى.

ثم ترسل أمر التشغيل، ولا يستجيب المصباح.

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

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

اكتشاف الجهاز يعني أنه متاح للضم

يمكن للجهاز غير المزوّد أن يعلن عن نفسه عبر Unprovisioned Device Beacon. يكتشفه الهاتف أو البوابة، ويبدأ الطرف الذي يتولى دور Provisioner العملية.

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

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

Provisioning ينشئ هوية الشبكة

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

بعد الانتهاء يصبح الجهاز عقدة، ولديه NetKey أولي وIV Index وعنوان أحادي الوجهة مخصص والمفتاح DevKey. يشتق الطرفان DevKey بصورة مستقلة؛ ولا يُرسل عبر الهواء كحقل إعداد بنص واضح. وظيفته تختلف عن NetKey المشترك.

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

ثلاثة مفاتيح بثلاث مسؤوليات

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

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

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

اقرأ تركيب الجهاز قبل تخمين العنوان

يتواصل Configuration Client مع Configuration Server في العقدة لقراءة الإعدادات وتغييرها. توضح Composition Data العناصر ونماذجها وقدراتها ذات الصلة.

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

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

إضافة AppKey وربط النموذج عمليتان منفصلتان

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

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

يحتاج المرسل أيضًا إلى المفتاح وإعداد النموذج الصحيحين؛ إعداد المصباح وحده لا يكمل العلاقة. وليست كل النماذج مستخدمة لـAppKey: نماذج Configuration تستخدم DevKey، فلا تعاملها كنماذج الإضاءة.

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

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

شغّل مصباحًا واحدًا قبل المجموعة

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

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

بعد نجاحه، أضف المجموعة. للتحكم في عدة مصابيح ممر من مفتاح جداري:

• ينشر نموذج العميل المناسب في المفتاح إلى عنوان المجموعة.
• تشترك نماذج الخادم المناسبة في المصابيح في ذلك العنوان.
• يستخدم الطرفان AppKey وإعدادات نماذج متوافقة.

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

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

النشر يحدد أيضًا وجهة الحالة

قد يرد المصباح على طلب يستلزم الرد، بينما يتطلب تغيّر حالته بزر محلي تقريرًا تلقائيًا. هذان مساران مختلفان.

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

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

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

الإعداد يحتاج إلى التعافي، لا تسلسل أوامر فقط

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

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

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

إعادة المصنع ليست أول حل لكل خطأ؛ فهي تغير الحالة وقد تكسر روابط قائمة. ميّز بين جهاز لم ينضم، وعقدة انضمت ولم تُهيأ، وعقدة مهيأة فقدت جهة الإدارة سجلاتها.

اربط الأعراض بطبقات الفحص

العَرَض	ما يُفحص أولًا
يُكتشف لكن يفشل Provisioning	وضع الضم وناقل الاتصال والمصادقة والأخطاء
ينجح الضم وتنتهي مهلة الإعداد	العناوين وDevKey وسياق الشبكة والوصول وربط الرد؛ وتوقيت استقبال LPN
يعمل الإعداد ويفشل التحكم الفردي	العنصر والنموذج وإضافة AppKey وربطه وإعداد المرسل
يعمل الفردي وتفشل المجموعة	الوجهة الفعلية والاشتراكات والمفاتيح والإرسال
يعمل التحكم ولا تتجدد الحالة	الردود والنشر التلقائي والاستقبال وربط الحالة بالأعلى
يفشل بعد إعادة التشغيل	التخزين والعناوين واستعادة الإعداد وسياق المفاتيح

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

تحقق من التحكم الفردي وقراءة الحالة، ثم المجموعة والتقارير بعد التغييرات المحلية، ثم انقطاع الإعداد وإعادة التشغيل. معيار نجاح واضح لكل مرحلة أنفع من عبارة «أضاء المصباح» فقط.

إضافة الجهاز عملية متعددة المراحل

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

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

نعود في المقال التالي إلى Xiaomi Mesh: ما تعريفات المنتج والهوية ومتطلبات منصة Xiaomi Home التي تُضاف فوق الشبكة والنماذج المعيارية؟

المراجع

• Bluetooth SIG: Mesh Networking Primer: العناوين والنشر والاشتراك والمفاتيح والتزويد والإعداد.
• Silicon Labs: Configuration Client API: تركيب الجهاز والمفاتيح والربط والاشتراك والنشر. ارجع إلى نسخة SDK المعتمدة لديك.